Identifying fraudulent online applications

ABSTRACT

A method of using browsing activity to identify fraudulent online or virtual applications includes receiving a virtual application over one or more radio frequency links, determining an applicant name on the virtual application, determining an IP address of a source computer from which the virtual application originated, determining an online browsing or search history associated with the IP address, determining whether the online browsing or search history indicates recent Internet searches for the applicant name, and, in response to determining that the online browsing or search history does indicate recent Internet searches for the applicant name, flagging the virtual application as fraudulent and generating an electronic alert indicating that the virtual application is fraudulent to facilitate identifying fraudulent virtual applications for goods or services.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims the benefit of U.S.Pat. No. 17,827,015, filed on May 27, 2022, and entitled “IdentifyingFraudulent Online Applications,” which claims the benefit of U.S. Pat.No. 16,913,814, filed on Jun. 26, 2020, and entitled “IdentifyingFraudulent Online Applications,” which claims the benefit of U.S. patentapplication Ser. No. 15/465,874, filed on Mar. 22, 2017, now U.S. Pat.No. 10,825,028, issued on Nov. 3, 2020 and entitled “IdentifyingFraudulent Online Applications,” which claims the benefit of U.S. PatentApplication No. 62/313,196, filed on Mar. 25, 2016 and entitled“Reducing Financial Fraud Using Machine Learning and Other Techniques,”U.S. Patent Application No. 62/318,423, filed on Apr. 5, 2016 andentitled “Reducing Financial Fraud Using Machine Learning and OtherTechniques,” U.S. Patent Application No. 62/331,530, filed on May 4,2016 and entitled “Reducing Financial Fraud Using Machine Learning andOther Techniques,” and U.S. Patent Application No. 62/365,699, filed onJul. 22, 2016 and entitled “Detecting and/or Preventing Financial FraudUsing Geolocation Data,” the disclosures of which are herebyincorporated herein by reference in their entireties.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to financial fraud and, morespecifically, to processing techniques that use machine learning toidentify application-related to fraud (e.g., fraudulent onlineapplications).

BACKGROUND

Financial fraud, in its many forms, is a problem of enormous magnitudeand scope, causing billions of dollars in economic losses and impactingmany millions of people. Types of financial fraud include use of a lostor stolen card, account takeover, skimming, chargeback (“friendly”)fraud, counterfeiting, forgeries and application (e.g., loanapplication) fraud, to name just a few. The problem only continues togrow as various technological advances, intended to improve convenienceand efficiency in the marketplace, provide new opportunities for badactors. For example, an ever-increasing amount of fraud may be linked toonline transactions made via the Internet.

Various software applications have been developed to detect potentiallyfraudulent transactions. For example, dollar amounts and geographiclocations have generally been used to flag particular credit or debitcard transactions, with cardholders then being contacted by employees ofthe card issuer to determine whether the transactions were indeedfraudulent. To ensure that most instances of fraud are captured,however, such techniques generally have a low threshold for triggering afraud alert. As a result, numerous fraud alerts are false positives. Theprevalence of false positives leads to a large cost in terms of thedrain on human resources (e.g., calling customers to discuss eachsuspect transaction, and/or other manual investigation techniques), andconsiderable distraction or annoyance for cardholders. To provide asolution to these shortcomings in the field of automated frauddetection, innovative processing techniques capable of reducing falsepositives are needed.

Other conventional processes relating to financial fraud are likewiseresource-intensive. For example, card issuers today perform manualreviews of fraudulent transactions to determine whether, under thelengthy and complex rules of a particular card network, chargebacks areappropriate (i.e., payments from the merchant or acquiring/merchant bankback to the card issuer). These manual reviews are another significantdrain on human resources, and may be subject to human error. Moreover,failure to properly identify chargeback scenarios may cost the cardissuer money.

As another example, application fraud (e.g., obtaining a loan in thename of another person) may sometimes not be discovered until the loanhas been made. By that point in time, any losses might not be fullyrecoverable.

BRIEF SUMMARY

The present embodiments may, inter alia, automatically detectapplication fraud. The detection may be based upon various types ofinformation, and the rules used to detect such scenarios may begenerated by a machine learning program.

In one embodiment, a computer-implemented method of using browsingactivity to identify fraudulent online or virtual applications includes:(1) receiving, by one or more processors and via one or moretransceivers, a virtual application over one or more radio frequencylinks; (2) determining, by the one or more processors, an applicant nameon the virtual application; (3) determining, by the one or moreprocessors, an IP address of a source computer from which the virtualapplication originated; (4) determining, by the one or more processors,an online browsing or search history associated with the IP address; (5)determining, by the one or more processors, whether the online browsingor search history indicates recent Internet searches for the applicantname; and/or (6) in response to determining that the online browsing orsearch history does indicate recent Internet searches for the applicantname, (i) flagging, by the one or more processors, the virtualapplication as fraudulent and (ii) generating an electronic alertindicating that the virtual application is fraudulent to facilitateidentifying fraudulent virtual applications for goods or services. Themethod may include additional, less, or alternate actions, includingthose discussed elsewhere herein.

In another embodiment, a computer system is configured to use IPaddresses and browsing activity to identify fraudulent virtualapplications. The computer system includes one or more transceivers, andone or more processors configured to: (1) receive, via the one or moretransceivers, a virtual application over one or more radio frequencylinks; (2) determine an applicant name on the virtual application; (3)determine an IP address of a source computer from which the virtualapplication originated; (4) determine an online browsing or searchhistory associated with the IP address; (5) determine whether the onlinebrowsing or search history indicates recent Internet searches for theapplicant name; and/or (6) in response to determining that the onlinebrowsing or search history does indicate recent Internet searches forthe applicant name, (i) flag the virtual application as fraudulent and(ii) generate an electronic alert indicating that the virtualapplication is fraudulent to facilitate identifying fraudulent virtualapplications for goods or services. The computer system may includeadditional, less, or alternate functionality, including that discussedelsewhere herein.

In another embodiment, a non-transitory, computer-readable mediumstoring instructions that, when executed by one or more processors,cause the one or more processors to: (1) receive, via one or moretransceivers, a virtual application over one or more radio frequencylinks; (2) determine an applicant name on the virtual application; (3)determine an IP address of a source computer from which the virtualapplication originated; (4) determine an online browsing or searchhistory associated with the IP address; (5) determine whether the onlinebrowsing or search history indicates recent Internet searches for theapplicant name; and/or (6) in response to determining that the onlinebrowsing or search history does indicate recent Internet searches forthe applicant name, (i) flag the virtual application as fraudulent and(ii) generate an electronic alert indicating that the virtualapplication is fraudulent to facilitate identifying fraudulent virtualapplications for goods or services.

BRIEF DESCRIPTION OF THE DRAWINGS

The Figures described below depict various aspects of the systems andmethods disclosed herein. It should be understood that each Figuredepicts an embodiment of a particular aspect of the disclosed systemsand methods, and that each of the Figures is intended to accord with apossible embodiment thereof.

FIG. 1 depicts an exemplary environment in which techniques for frauddetection, verification and/or classification may be implemented,according to one embodiment.

FIG. 2 depicts an exemplary process flow for machine learning of frauddetection, verification and/or classification rules, according to oneembodiment.

FIGS. 3A-3F depict exemplary process flows for machine learning ofparticular types of fraud detection, verification and/or classificationrules, according to different embodiments.

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection, verification and/orclassification rule sets, according to different embodiments.

FIG. 5 depicts a flow diagram of an exemplary method for identifying apotential chargeback scenario, according to one embodiment.

FIG. 6 illustrates an exemplary computer-implemented method ofdetermining that a merchant computer terminal warrants a chargebackafter a consumer dispute or fraudulent transaction occurs based upondispute rules.

FIG. 7 illustrates an exemplary computer-implemented method of detectingor identifying potentially compromised merchant computing systems basedupon processor analysis of electronically-generated chargebacks oractual losses.

FIG. 8 illustrates an exemplary computer-implemented method of detectingor determining potentially compromised merchant computing systems basedupon processor analysis of electronically-generated fraud alerts.

FIG. 9 depicts a flow diagram of an exemplary method for detectingpotential application fraud, according to one embodiment.

FIG. 10 illustrates an exemplary computer-implemented method of using IPaddress and/or browsing activity to identify fraudulent online orvirtual applications, according to one embodiment.

FIG. 11 illustrates an exemplary computer-implemented method ofdetecting or identifying potential mortgage fraud.

FIG. 12 depicts an exemplary computer system in which the techniquesdescribed herein may be implemented, according to one embodiment.

DETAILED DESCRIPTION I. Exemplary Fraud Detection and/or Classification

The embodiments described herein relate to, inter alia, wholly orpartially automated detection, verification and/or classification offinancial fraud. For ease of explanation, and unless otherwise clearlyindicated by the context of usage, “detecting” or “determining” fraudmay be used herein to refer to initially flagging fraudulent (orpotentially fraudulent) activity, to verifying/confirming thatsuspect/flagged activity was indeed fraudulent, or generally to both.The systems and techniques described herein may be used, for example, toidentify, prevent and/or quantify/measure instances of lost or stolencard use, account takeover, counterfeiting, skimming, chargeback(“friendly”) fraud, collusive merchant fraud, application (e.g., loanapplication) fraud, mortgage fraud, and/or one or more other types offraud relating to existing and/or potential financial transactionsand/or accounts. Moreover, those skilled in the art will appreciate thatat least some of the technical advancements described below (and/orshown in the accompanying figures) are not necessarily restricted to thefinancial field.

In some embodiments, a fraud detection and/or classification system mayanalyze data relating to a number of existing or potential financialaccounts. The analysis/processing may be performed in batch processingoperations, or substantially in real-time (e.g., as the data isgenerated and/or as financial transactions occur, etc.), and the datamay be obtained from a variety of sources based upon the particularembodiment and/or scenario. In one embodiment, for example, data fromfinancial account records may be analyzed, along with data indicatingonline activity of an account holder, location data (e.g., globalpositioning satellite (GPS) data from a smartphone or vehicle of theaccount holder) and/or other data, to determine whether a particularfinancial transaction was fraudulent or likely fraudulent. The analysismay be performed automatically after the transaction has been made, ormay be performed in response to a person or algorithm flagging thetransaction as a potentially fraudulent one, for example.

The analysis may include determining whether the account holder hasexpressed interest in the object (e.g., product or service) of thetransaction or the merchant, and/or determining whether the transactionis consistent with spending patterns associated with the account holder(e.g., spending patterns identified using the account holder'stransaction records), for example. In the case of multiple accountholders (e.g. multiple credit or debit card holders), accuracy may beimproved by identifying spending patterns at the individual level ratherthan, or in addition to, at the aggregate account level. For example, amaximum amount of money typically spent in a single transaction (e.g.,over the course of a one-month window, etc.) may be determined for eachof two cardholders listed on a single account, and the maximum amountfor the cardholder who purportedly made a particular purchase may becompared to the purchase amount to determine whether fraud is suspected.

In another exemplary embodiment, financial transaction data may beanalyzed to determine whether a chargeback payment from the merchant oracquiring bank to a card issuer may be appropriate in connection with aparticular fraudulent transaction. For example, the card informationentry mode (e.g., collecting card information by inserting the card in achip reader, swiping the card, manually entering the card information,etc.), the transaction amount, the similarity to other transaction(s),and/or other information may be used to identify which fraudulenttransactions are relatively strong chargeback candidates. The analysismay be performed in response to a cardholder reporting the transactionas fraudulent, or after a card issuer has confirmed that the transactionwas fraudulent, for example. For the subset of instances where afraudulent transaction has been identified as a chargeback candidate, afull set of chargeback rules (e.g., devised by a card network entitysuch as VISA®, Mastercard®, American Express®, Discover®, etc.) may bemanually or automatically applied to determine whether a chargebackprocess should be initiated (or continued).

In another exemplary embodiment, application data (e.g., informationentered in fields of an online application) may be analyzed inconjunction with search terms entered by a user at a computing device(e.g., the device from which the user submitted the applicationinformation) to determine whether the person proffering the applicationis not the person that he or she purports to be. For example, if theperson submitting an application had previously used an Internet-basedsearch engine to search for results associated with the purportedapplicant's name (e.g., by using the name as a search term, possibly inaddition to other terms such as “address” and/or “employer,” etc.), theapplication may be flagged for suspected fraud, and subjected toadditional steps of manual and/or automated review.

In another exemplary embodiment, a fraud dispute resolution process(e.g., after a customer has reported a fraudulent or unrecognizedtransaction associated with his or her account) may be facilitated usingmachine learning techniques. For example, a machine learning program maybe trained, using past dispute resolution interactions with customersand the associated outcomes (fraud determinations), to identify varioustypes of information that, if elicited from customers, tend to beindicative of fraud or the absence thereof. When fraud is suspected fora particular transaction, one or more queries for the individualpurportedly making the transaction may be automatically generated usingthe types of information identified by the machine learning program, aswell as information about the suspect transaction and/or relatedtransactions (e.g., dates, locations, amounts, etc.). In someembodiments and/or scenarios, responses to the queries may be collectedand analyzed to automatically generate additional queries, with the endgoal of discerning whether the transaction was authorized. For example,queries may include asking whether a cardholder recalls particular othertransactions that appear on the cardholder's account and were madearound the same time as the suspect transaction (and/or from the samemerchant), asking whether the cardholder recalls being in a particularlocation at a particular time (e.g., a location associated with anothertransaction appearing on the cardholder's account), whether thecardholder is aware of a particular billing alias used by a merchant,and so on.

In another exemplary embodiment, image data corresponding to aparticular physical document (e.g., a personal or cashier's check, adriver's license or other identification card, etc.) may be analyzed,using rules generated by a machine learning program, to determinewhether the document is, or may be, fraudulent (e.g., a counterfeitdocument, and/or a document that includes forged contents). For example,the machine learning program may be trained using images of multipleother documents, and fraud determinations made in connection with thoseother documents. The machine learning program may learn which rangesand/or tolerances for dimensions, fonts, colors, patterns, etc., tend tobe most indicative of counterfeiting, for example. A forgery may bedetected based upon factors relating to the contents of various fieldsin a document, such as whether handwriting, a signature, and/or a dateformat (e.g., “Jan. 1, 2016,” “1/1/16,” etc.) matches that used forother personal checks from a particular account holder, for example. Thefraud determination may be made substantially in real-time to provide awarning, if needed, to a merchant making a sale, for example, or may beused to flag a relatively small number of documents for physical reviewat a later time, etc.

In another exemplary embodiment, machine learning techniques may be usedto analyze financial transactions for purposes of classifyingpotentially fraudulent behavior (e.g., “counterfeiting,” “skimming,”“lost or stolen card,” etc.). For example, the machine learning programmay be trained using fraud classifications made in connection withmultiple other financial accounts. The machine learning program maylearn which types of data tend to be indicative of differentclassifications (e.g., transaction amount, credit card information entrymode, particular types of online activity data, etc.), and/or which datavalues tend to be indicative of different classifications (e.g.,transactions over $10,000, manual card number entry, etc.), for example.Once a class of potential fraud has been identified for a particulartransaction, the classification may be used to facilitate or guide afurther, more in-depth analysis or investigation. Alternatively, or inaddition, the classification may be used to calculate one or moremetrics indicating the prevalence of that type of fraud.

By replacing conventional processing techniques with one or more of theprocessing techniques described herein, problems that have beset thefield of fraud detection, classification and/or prevention in the pastmay be greatly mitigated or eliminated. For example, information thathas conventionally been overlooked or ignored may be used to moreaccurately detect, prevent and/or classify fraud, and/or to reduce falsepositive fraud alerts. As another example, a significant amount of timemay be saved by removing the need for manual investigations, or byreducing the number of instances where manual investigations arerequired.

II. Exemplary Environment for Implementing Fraud Detection and/orClassification Processing Techniques

FIG. 1 depicts an exemplary environment 10 in which techniques for frauddetection and/or classification may be implemented, according to oneembodiment. The environment 10 may include an anti-fraud services system(AFSS) 12, a financial account management system (FAMS) 14, a cardnetwork computing system 16, a number of cardholder computing devices20, a number of merchant computing systems 22, a number of other sources24, and a network 26. It is noted that, in other embodiments and/orscenarios, the environment 10 may include more, fewer and/or differentcomponents than those shown in FIG. 1 , such as any of those discussedelsewhere herein. For example, the environment 10 may include one ormore additional financial account management systems and/or card networkcomputing systems, and/or one or more of the cardholder computingdevices 20 may instead be a computing device of a holder of a non-cardaccount (e.g., a checking, savings or loan account) or an applicant fora new account (e.g., a new loan account). As another example, theenvironment 10 may include a computing system of one or moreacquiring/merchant banks, and some or all of the communications withmerchant computing systems 22 described below may instead be with theacquiring bank(s).

FAMS 14 may be associated with (e.g., owned and/or maintained by) a bankor other financial entity. For example, FAMS 14 may be a bank that actsas a card issuer associated with a particular type of card network(e.g., VISA®, Mastercard®, etc.), and/or an entity that provides loans(e.g., mortgage, home equity, vehicle, etc.), saving/checking accountservices, and/or other financial services to customers. FAMS 14 maymaintain an account records database 30 that stores various kinds ofaccount information, including account holder information (e.g., names,addresses, etc.) and data indicative of financial transactions made inconnection with each account (e.g., dates, amounts and merchants forcredit or debit card transactions, dates and amounts for customerdeposits and withdrawals, etc.). Account records database 30 may storeaccount information for some or all of the cardholders associated withcardholder computing devices 20, for example. While shown in FIG. 1 as asingle entity within FAMS 14, it is understood that account recordsdatabase 30 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) FAMS 14.

AFSS 12 may generally provide services that help to detect and/orclassify fraudulent activity in connection with existing and/orpotential (e.g., applied for) financial accounts, such as the accountsmanaged by FAMS 14. In some embodiments, AFSS 12 is included within FAMS14. As seen in FIG. 1 , AFSS 12 may include a network interface 32, amemory 34, and a fraud detection/classification unit 36.

Network interface 32 may include hardware, firmware and/or softwareconfigured to enable AFSS 12 to wirelessly exchange electronic data withone or more other components of environment 10 via network 26. Forexample, network interface 32 may include an Ethernet port, a modem, arouter, and/or one or more other ports and/or transceivers for one ormore other wired and/or wireless communication technologies.

Memory 34 may be a computer-readable, non-transitory storage unit ordevice, or collection of units/devices, and may include persistent(e.g., hard disk) and/or non-persistent memory components. Memory 34 maystore instructions that are executable on one or more processors of AFSS12 (not shown in FIG. 1 ) to perform various operations, including theinstructions of various software applications and data generated and/orused by such applications.

Card network computing system 16 may be a computing system (e.g., one ormore servers) of a credit and/or debit card network entity, such asVISA® or Mastercard®, for example. In some embodiments and/or scenarioswhere the card network entity also acts as the issuer (e.g., AmericanExpress® or Discover®), card network computing system 16 may includeFAMS 14. Card network computing system 16 may provide various servicesto FAMS 14 and/or AFSS 12. For example, card network computing system 16may provide electronic updates to chargeback rules, fraud scores forparticular customers and/or transactions, and so on.

Each of cardholder computing devices 20 may be a computing device of arespective holder of a credit or debit card account managed by FAMS 14.For example, one or more of cardholder computing devices 20 may bedesktop computers, laptop computers, tablet computers, smartphones,smart watches, and so on. The cardholders (e.g., credit or debit cardaccount holders) may use cardholder computing devices 20 to access(e.g., view, modify, etc.) their account information stored in accountrecords database 30 online via network 26. In some embodiments whereAFSS 12 detects and/or classifies activity not related to credit ordebit card fraud (e.g., a fraudulent application for a home equity loan,etc.), cardholder computing devices 20 may instead be computing devicesof other types of customers or potential customers, such as holders ofnon-card-based accounts, or individuals who have submitted an onlineapplication for a loan, etc., as discussed further below. In some ofthese embodiments, the environment 10 may omit card network computingsystem 16.

Each of merchant computing systems 22 may include one or more computingdevices associated with a particular provider of products and/orservices. For example, some or all of merchant computing systems 22 mayinclude servers associated with online retailers. Alternatively, oradditionally, some or all of merchant computing systems 22 may includepoint-of-sale terminal devices providing credit and/or debit cardpayment processing features for “card present” transactions. In someembodiments where AFSS 12 detects and/or classifies activity not relatedto customer purchases (e.g., if AFSS 12 only detects loan applicationfraud, etc.), the environment 10 may omit merchant computing systems 22.

The other sources 24 may include computing devices and/or systemsassociated with sources of one or more other types of information. Forexample, other sources 24 may include vehicle telematics systems (e.g.,installed in vehicles of cardholders associated with cardholdercomputing devices 20), one or more Internet service providers (ISPs)(e.g., ISPs providing Internet access to some or all cardholders),“smart home” system devices (e.g., installed in homes of some or allcardholders), and/or other systems/devices. In some embodiments, theenvironment 10 does not include the other sources 24.

Network 26 may communicatively couple some or all of the componentsshown in FIG. 1 . For example, FAMS 14 may use network 26 to communicatewith AFSS 12, card network computing system 16, cardholder computingdevices 20 and/or merchant computing systems 22. As another example,AFSS 12 may use network 26 to communicate with FAMS 14, card networkcomputing system 16, cardholder computing devices 20, merchant computingsystems 22 and/or one or more of the other sources 24. While shown as asingle entity in FIG. 1, network 26 may include multiple communicationnetworks of one or more types (e.g., one or more wired and/or wirelesslocal area networks (LANs), and/or one or more wired and/or wirelesswide area networks (WANs) such as the Internet). Moreover, network 26may use partially or entirely distinct network components to supportcommunications between different endpoints or computing devices, such aswireless communication or data transmission over one or more radiofrequency links and/or wireless communication channels. For example, theportion(s) of network 26 used for communications between FAMS 14 andAFSS 12 may be the same as, or different than, the portion(s) of network26 used for communications between FAMS 14 and one or more of cardholdercomputing devices 20 over one or more radio links or wirelesscommunication channels, or between AFSS 12 and one or more of the othersources 24, etc. Those skilled in the art will appreciate differenttypes of networks that are appropriate for network 26, depending upon,for example, how AFSS 12, FAMS 14 and/or other components of environment10 are localized or distributed across a relatively large geographicarea.

Generally, fraud detection/classification unit 36 of AFSS 12 may detectfraudulent activity, confirm whether suspected or reported fraudulentactivity is truly fraudulent, and/or classify fraudulent or suspectedfraudulent activity. For example, fraud detection/classification unit 36may analyze each transaction stored in account records database 30 todetermine whether that transaction is, or potentially is, fraudulent.Alternatively, fraud detection/classification unit 36 may analyze onlythose transactions that were flagged as possibly being fraudulent (e.g.,by a cardholder calling in to report an unauthorized and/or unrecognizedtransaction, or by FAMS 14 or AFSS 12 generating a preliminary fraudalert after applying an initial set of rules to a transaction, etc.).Fraud detection/classification unit 36 may also, or instead, supportadditional functionality, such as that described below in connectionwith the various components of fraud detection/classification unit 36shown in FIG. 1 .

As seen in FIG. 1 , fraud detection/classification unit 36 may include amachine learning (ML) rule generator 40, an external data collectionunit 42, a behavior analysis unit 44, a dispute resolution unit 46, achargeback analysis unit 50, an image analysis unit 52, a classificationunit 54, and/or a notification unit 56. In other embodiments, frauddetection/classification unit 36 may include more, fewer and/ordifferent components/units than those shown in FIG. 1 . In someembodiments, each of ML rule generator 40, external data collection unit42, behavior analysis unit 44, dispute resolution unit 46, chargebackanalysis unit 50, image analysis unit 52, classification unit 54,notification unit 56, and/or other units or components of frauddetection/classification unit 36 may be a software component stored inmemory 34 and implemented by one or more processors of one or morecomputing devices (e.g., servers) included in AFSS 12.

ML rule generator 40 may generally analyze various types of data togenerate and/or update fraud detection and/or classification rules to beapplied by fraud detection/classification unit 36 and stored in an MLrules database 58. As discussed in further detail below, the rules maybe used to detect and/or classify a single type or category offraudulent activity, or may be used broadly in connection with multipletypes or categories of fraudulent activity. ML rule generator 40 mayimplement any suitable type or types of machine learning. For example,ML rule generator 40 may implement supervised learning techniques, suchas decision trees, regression-based models, support vector machines(SVMs) and/or neural networks, and/or unsupervised learning techniquessuch as Dirichlet process mixture models and/or k-means clustering.Other machine learning techniques are also possible, such as techniquesutilizing Bayesian networks, “deep learning” techniques, and so on.While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that ML rules database 58 may, in some embodiments, bedistributed across multiple databases and/or multiple physical/hardwarememories, and/or may be wholly or partially external to (e.g., remotefrom) AFSS 12.

External data collection unit 42 may generally collect, via networkinterface 32 and/or from sources internal to AFSS 12, information fromvarious sources (e.g., FAMS 14, cardholder computing devices 20, othersources 24, etc.), and provide that data to other portions of AFSS 12 asneeded (e.g., to ML rule generator 40 to generate and/or update rules,and/or to behavior analysis unit 44, dispute resolution unit 46,chargeback analysis unit 50, image analysis unit 52 and/orclassification unit 54 to detect and/or classify fraudulent activity).Some data may be collected indirectly. For example, FAMS 14 may collecttransaction data from merchant computing systems 22 (and/or fromacquiring banks associated with one or more of merchant computingsystems 22), and external data collection unit 42 may then collect thatdata from the account records database 30 of FAMS 14.

Once an initial set of rules has been generated and stored in ML rulesdatabase 58, those rules may dictate some or all of the types of datagathered by external data collection unit 42. In some embodiments,however, external data collection unit 42 collects a broad set of datatypes that may or may not be relevant to fraud determination orclassification, and ML rule generator 40 continually analyzes that datato determine which data types are most predictive of fraud and/or fraudtype/class.

Behavior analysis unit 44 may generally analyze cardholder-related (orother customer-related) information to identify patterns of behavior,which may then be used by fraud detection/classification unit 36 todetect and/or classify fraudulent activity. For example, behavioranalysis unit 44 may analyze information obtained from account recordsdatabase 30 to identify spending patterns associated with differentcardholders. The operation of behavior analysis unit 44, including thetypes of information analyzed and the ways in which that information isused to arrive at a result (e.g., a pattern of behavior), may bedictated by the rules stored in ML rules database 58.

Data indicative of the behavior patterns identified by behavior analysisunit 44 may be stored in an account holder behaviors database 60, forexample. While shown in FIG. 1 as a single entity within AFSS 12, it isunderstood that account holder behaviors database 60 may, in someembodiments, be distributed across multiple databases and/or multiplephysical/hardware memories, and/or may be wholly or partially externalto (e.g., remote from) AFSS 12. In one embodiment, for example, accountholder behaviors database 60 may be included within account recordsdatabase 30. In still other embodiments, the environment 10 may notinclude account holder behaviors database 60, and behavior patterns maybe only identified by behavior analysis unit 44 “on the fly” as neededby fraud detection/classification unit 36 (e.g., when needed to analyzea transaction in view of past spending patterns of a particularcardholder, etc.).

In some embodiments, behavior analysis unit 44 may separately analyzethe transactions associated with each account holder, even if more thanone account holder exists for a particular account. For example,behavior analysis unit 44 may independently analyze the transactions ofeach cardholder for a credit or debit card account in which each spousehas been issued a credit or debit card in his or her name. Frauddetection/classification unit 36 may then utilize the individualspending patterns when detecting and/or classifying fraud. In oneembodiment where fraud detection/classification unit 36 utilizes adollar amount threshold to detect likely fraudulent transactions, forexample, a first threshold may be used for transactions made by a firstcardholder listed on an account, and a higher, second threshold may beused for transactions made by a second cardholder listed on the account.Further examples are provided below in connection with FIG. 6 ,according to various embodiments. In this manner, fraud detection and/orclassification may be made more precise than would be the case ifspending patterns were only identified at the aggregate level (e.g.,using a single dollar amount threshold, regardless of which cardholdermade a particular transaction).

Dispute resolution unit 46 may generally analyze financial transactiondata and/or other information to automatically generate queries forcardholders or other customers. For example, dispute resolution unit 46may analyze information obtained from account records database 30. Thegenerated queries may be designed to help fraud detection/classificationunit 36 determine whether a particular transaction was fraudulent, orestimate a probability that the transaction was fraudulent, etc. Disputeresolution unit 46 may also process responses fromcardholders/customers, and automatically generate additional queriesbased upon those responses. Examples of the operation of disputeresolution unit 46 are provided below in connection with FIGS. 4E and 9, according to various embodiments.

Chargeback analysis unit 50 may generally analyze financial transactionand/or other information to identify transactions that are goodcandidates for chargeback payments. For example, chargeback analysisunit 50 may analyze information obtained from account records database30 to determine whether there is a relatively high probability that themerchant (or an acquiring bank) should be responsible for a chargebackpayment to a card issuer associated with FRMS 14. The operation ofchargeback analysis unit 50, including the types of information analyzedand the ways in which that information is used to arrive at a result(e.g., flagging a transaction as a chargeback candidate), may bedictated by the rules stored in ML rules database 58. ML rule generator40 may make use of chargeback rules obtained from a card network entity(e.g., from card network computing system 16), and stored in chargebackrules database 62, to generate and/or update the rules applied bychargeback analysis unit 50. Examples of the operation of chargebackanalysis unit 50 are provided below in connection with FIGS. 4B and 7 ,according to various embodiments.

In some embodiments, transactions flagged by chargeback analysis unit 50are subject to further, manual review using the chargeback rules storedin chargeback rules database 62. In other embodiments, chargebackanalysis unit 50 (or another component of fraud detection/classificationunit not shown in FIG. 1 ) automatically, with little or no manualinput/assistance, applies the chargeback rules from chargeback rulesdatabase 62 for each flagged transaction. While shown in FIG. 1 as asingle entity within AFSS 12, it is understood that chargeback rulesdatabase 62 may, in some embodiments, be distributed across multipledatabases and/or multiple physical/hardware memories, and/or may bewholly or partially external to (e.g., remote from) AFSS 12.

Image analysis unit 52 may generally analyze image data corresponding tophysical documents to identify fraudulent (e.g., counterfeit and/orforged) documents, and/or to flag potentially fraudulent documents forfurther (e.g., manual) review. For example, image analysis unit 52 mayanalyze information obtained from merchant computing systems 22 todetermine whether there is a relatively high probability that documentspresented to the merchants (e.g., personal checks, identification cards,etc.) are fraudulent. Image analysis unit 52 may be configured toanalyze only a single type of document, or multiple types of documents.The operation of image analysis unit 52, including the imagecharacteristics analyzed and the ways in which the characteristics maybe used to arrive at a result (e.g., flagging a document as potentiallyfraudulent), may be dictated by the rules stored in ML rules database58. Examples of the operation of image analysis unit 52 are providedbelow in connection with FIGS. 4F and 10 , according to variousembodiments.

Classification unit 54 may generally analyze broad categories of datafrom various sources (e.g., account records database 30, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24) to categorize/classify types of suspected fraudulentfinancial activity. Classification unit 54 may classify fraudulentactivity only within a particular subset of fraudulent financialactivity (e.g., classifying debit and/or credit card transactions asinvolving a potential case of counterfeiting, skimming, lost/stolen carduse, chargeback fraud, etc.), or may classify fraudulent financialactivity across a broader spectrum (e.g., including types of identitytheft not necessarily tied to a single financial transaction, such asapplication fraud). In some embodiments, classification unit 54classifies suspected fraudulent activity in connection with a particularaccount or transaction in response to being notified of suspect activity(e.g., notified by another component of fraud detection/classificationunit 36, or by a manual user input, etc.). In other embodiments,classification unit 54 itself (or another component of frauddetection/classification unit 36) identifies suspect activity beforeclassification unit 54 classifies that activity. Examples of theoperation of classification unit 54 are provided below in connectionwith FIGS. 4C and 11 , according to various embodiments.

Notification unit 56 may generally provide alerts, confirmations, and/orother notifications to various individuals (e.g., customers, bankemployees associated with FAMS 14, third party employees associated withAFSS 12, etc.). For example, notification unit 56 may generate anotification message stating that a fraud alert associated with aparticular transaction is a false positive, and cause network interface32 to send the message to a computer terminal or to FAMS 14 for displayto a system user. As another example, notification unit 56 may causenetwork interface 32 to send other flagged transactions and/or documents(e.g., chargeback candidates identified by chargeback analysis unit 50,documents that image analysis unit 52 has identified as potentiallyfraudulent, etc.) to a computer terminal or FAMS 14 for display to asystem user. As yet another example, notification unit 56 may causenetwork interface 32 to send queries generated by dispute resolutionunit 46 to various ones of cardholder computing devices 20 for displayto cardholders.

The operation of various components of the environment 10 shown in FIG.1 , according to different embodiments and/or scenarios, will bedescribed further below in connection with the remaining figures.

III. Exemplary Process Flows for Machine Learning of Fraud Detectionand/or Classification Rules

As discussed above, ML rule generator 40 may generate and/or updaterules that are used for one or more of a variety of different purposesrelating to fraud detection and/or classification. FIG. 2 depicts onegeneralized, example process flow 80 for machine learning that may beimplemented by ML rule generator 40, and possibly one or more othercomponents of fraud detection/classification unit 36.

In the process flow 80, multi-account data 82 may represent dataassociated with multiple financial accounts, each with one or moreaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 82 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 82 may include oneor more different types of information obtained (e.g., by external datacollection unit 42 of FIG. 1 ) from one or more of FAMS 14, cardholdercomputing devices 20, merchant computing systems 22, and/or othersources 24. For example, the multi-account data 82 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of InternetProtocol (IP) addresses of cardholder computing devices 20 and/ordevices in merchant computing systems 22, Internet browsing and/orsearch history data from cardholder computing devices 20 (or from an ISPcomputer system included in other sources 24, etc.), vehicle telematicsdata from telematics systems of cardholder vehicles, home occupancyand/or usage data (e.g., smart appliance data) from smart home systemsof cardholders, autonomous or smart vehicle data, vehicle navigationsystem data, mobile device data, mobile device and/or vehicle GPS data,and/or one or more other types of data. In some embodiments, themulti-account data 82 only includes data that account holders orpotential account holders have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services). In certain other embodiments, however,express consent is only needed for certain types of information, such asbrowsing history information, vehicle telematics data, etc.

The multi-account data 82 may be associated with multiple frauddetermination labels. The labels may simply reflect whether or not fraudexisted (e.g., “fraud” or “no fraud”), or may also indicate a type orclass of fraud (e.g., “counterfeiting,” “lost or stolen card use,”etc.), for example. In one embodiment, each of a number of data sets inthe multi-account data 82 is associated with such a label, and includesdata relating to a particular financial transaction, financial account,loan application, etc., for which the fraud determination was made(e.g., after a manual and/or automated fraud investigation). The labelsmay include final fraud determinations that were made via earlieriterations of the process flow 80, and/or external to the process flow80.

To provide a more detailed example, a first data set associated with a“card present” credit card transaction may include data describing thattransaction (e.g., from account records database 30) and data indicativeof the cardholder's online browsing activity (e.g., from one ofcardholder computing devices 20) for the 15 days immediately precedingthe transaction, and be labeled “confirmed fraud.” A second data set,associated with another “card present” transaction (for the sameaccount, or for a different account), may include the same general typesof data but be labeled “no fraud,” and so on. In some embodiments and/orscenarios, the same data may appear in, or be used by, two or more ofthe data sets. If the two “card present” transactions described aboveare both associated with the same account, for example, and if thesecond transaction occurred less than 15 days after the firsttransaction, some of the same online activity data may be shared by thefirst and second data sets.

At a process stage 84, the multi-account data 82 may be analyzed togenerate fraud detection and/or classification rules (e.g., to be storedin ML rules database 58). Any suitable type of supervised machinelearning program/technique(s) may be used, such as SVMs, neuralnetworks, logistic regression, etc. Generally, process stage 84 mayserve to identify which type(s) of data is/are probative of whetherfraud has occurred (and/or the type/category of fraud that may haveoccurred), and to determine the data values and/or combinations that areprobative of whether fraud has occurred (and/or the type/category offraud that may have occurred). By analyzing many (e.g., thousands) ofpositively and negatively labeled data sets in the multi-account data82, for example, process stage 84 may learn that certain spendingpatterns within a threshold time of a transaction tend to indicate thatthe cardholder made the transaction (e.g., thereby indicating that fraudhas not occurred, or that a fraud report is itself fraudulent ormistaken, etc.), that certain types of online searches by a cardholder(e.g., including a descriptor of a product purchased in the transaction,or a name of the merchant, etc.) tend to indicate that the cardholdermade the transaction, that the cardholder's distance from the site of a“card present” transaction (e.g., as determined from GPS informationprovided by the cardholder's smartphone, wearable electronics, orvehicle) relates to the probability of fraudulent activity according toa particular equation, and so on. Other specific examples of such rules,and how those rules may be generated, are discussed below in connectionwith FIGS. 3A-3F and 4A-4F, according to various embodiments.

At process stage 86, the rules generated or updated at process stage 84may be applied to first account data 90 associated with a particularaccount and customer(s) (e.g., a customer associated with a particularone of computing devices 20). The types of data included in firstaccount data 90 may depend upon which types of data were determined, byprocess stage 84, to be relevant to a fraud determination. For example,if the rules give weight to the amount and date of a financialtransaction when determining whether the transaction is fraudulent, andalso give weight to whether the account holder visits a particular typeof website, then the first account data 90 may include the amount anddate of one or more transactions, as well as data indicative of visitedweb sites (e.g., Uniform Resource Locators (URLs) and/or content ofvisited websites, etc.). The first account data 90 may includeinformation obtained (e.g., by external data collection unit 42) fromone or more of FAMS 14, one of cardholder computing devices 20associated with the customer holding the first account, one or more ofmerchant computing systems 22, and/or one or more of other sources 24,for example.

Process stage 86 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first account data 90 and the rules generated orupdated at process stage 84, process stage 86 may generate dataindicating that a particular financial transaction associated with firstaccount data 90 is, or is not, fraudulent or potentially fraudulent.Alternatively, or additionally, process stage 86 may generate dataindicating a particular classification for fraudulent or suspectedfraudulent activity (e.g., a fraudulent transaction) associated withfirst account data 90.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat an additional stage, shown in dashed lines in FIG. 2 as process stage92. The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 94. In otherembodiments, process stage 92 is omitted from process flow 80, andprocess stage 94 merely represents the output of process stage 86. Thefinal determination made at process stage 94, along with the firstaccount data 90 used to make that determination, may be fed back intoprocess stage 84 to provide additional labeled data for purposes ofupdating the rules.

In some embodiments, the process flow 80 includes more, fewer and/ordifferent stages, such as any of those discussed elsewhere herein (e.g.,in connection with FIGS. 3A-3F). In one alternative embodiment, processstages 84 and 86 may be combined. For example, the multi-account data 82may be unlabeled rather than labeled (or the labels may be ignored), andthe combined process stage 84, 86 may use unsupervised learningtechniques (e.g., clustering techniques) to classify anomalous/outlierfinancial transactions, accounts, applications, etc., as “suspect” andneeding further analysis.

More specific, machine learning-based process flows generallycorresponding to process flow 80 of FIG. 2 will now be described withreference to FIGS. 3A-3F. It is noted, however, that other process flowsare also within the scope of the invention described herein. Moreover,while FIGS. 3A-3F generally correspond to embodiments in whichsupervised machine learning techniques are used, other embodiments mayinstead use unsupervised machine learning techniques, as noted above. Invarious different embodiments, fraud detection/classification unit 36may be configured to implement only one of the process flows of FIGS.3A-3F, or may be configured to implement two or more (e.g., all) of theprocess flows shown in FIGS. 3A-3F.

A. Exemplary Process Flow for Machine Learning of Fraud Detection RulesUsing Online Activity Data

Referring first to FIG. 3A, an exemplary process flow 100 may generallybe used to detect fraud using customer online activity data. In theprocess flow 100, multi-customer online activity data 102 may representdata associated with the online activities of a number (e.g., thousands)of customers (e.g., credit or debit cardholders, checking or savingaccount holders, etc.). The multi-customer online activity data 102 mayinclude data indicating actions that the customers took, and/or websites visited by the customers, while the customers were connected tothe Internet via web browsers (e.g., executing on respective ones ofcardholder computing devices 20). For example, the multi-customer onlineactivity data 102 may include URLs of, and/or content (e.g., text)within, web sites visited by customers, search terms entered bycustomers using search engine tools, search results presented tocustomers by search engine tools, indications of interactive controls(e.g., virtual buttons) selected by customers on various web pages, andso on.

The multi-customer online activity data 102 may include data obtained(e.g., by external data collection unit 42 of FIG. 1 ) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-customer online activity data 102 may onlyinclude data that customers have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forfraud protection services or other benefits, such as discounts).

As described above in connection with multi-account data 82 of processflow 80, the multi-customer online account data 102 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that includes not only thecorresponding portion of multi-customer online activity data 102, butalso one or more other types of data, such as transaction data (e.g.,transaction dates, amounts, locations, etc.) for each customer fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofother sources 24, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of other sources 24, and so on.The labels may include final fraud determinations that were made viaearlier iterations of the process flow 100, and/or external to theprocess flow 100. Multi-customer online account data 102 may includemany (e.g., thousands) of positively and negatively labeled data sets.

At a process stage 104, the multi-customer online activity data 102 maybe analyzed to generate fraud detection rules (e.g., to be stored in MLrules database 58). As described above in connection with process stage84 of process flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 104 may serveto identify which type(s) of online activity data is/are probative ofwhether fraud has occurred, and to determine the data values and/orcombinations that are probative of whether fraud has occurred. While notshown in FIG. 3A, the fraud detection rules may not only detect fraud,but also classify fraud (e.g., as described below in connection withFIG. 3C), in some embodiments.

At process stage 106, the rules generated or updated at process stage104 may be applied to first customer online activity data 110. The firstcustomer online activity data 110 may be associated with a particularcustomer, such as a customer associated with a particular one ofcomputing devices 20, for example. The types of data included in firstcustomer online activity data 110 may depend upon which types of onlineactivity data were determined, by process stage 104, to be relevant to afraud determination. For example, the first customer online activitydata 110 may include information obtained (e.g., by external datacollection unit 42) from one of cardholder computing devices 20 (i.e.,the device associated with the first customer), and/or from an ISP ofother sources 24. Some specific examples of rules that may be generatedby process stage 104, and applied at process stage 106, are describedbelow in connection with FIG. 4A.

Process stage 106 may output various different types of information,depending upon the embodiment and/or scenario. For example, dependingupon the content of first customer online activity data 110 and therules, process stage 106 may generate data indicating that a particularfinancial transaction associated with the first customer is, or is not,fraudulent or potentially fraudulent. Alternatively, or additionally,process stage 106 may generate data indicating a particularclassification of fraudulent or potentially fraudulent activityassociated with first customer online activity data 110.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3A as process stage 112.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether fraud occurred, and/oron the type of fraud that occurred) at process stage 114. In otherembodiments, process stage 112 is omitted from process flow 100, andprocess stage 114 merely represents the output of process stage 106.

The final determination made at process stage 114, along with the firstcustomer online activity data 110 (and any other data) used to make thatdetermination, may be fed back into process stage 104 to provideadditional labeled data for purposes of updating the rules. In someembodiments, a preliminary fraud determination made at process stage 106is also fed back into process stage 104, to allow the machine learningprogram to determine and improve upon past performance/accuracy.

B. Exemplary Process Flow for Machine Learning of Chargeback CandidateDetection Rules

Referring next to FIG. 3B, an exemplary process flow 120 may generallybe used to identify the financial transactions for which chargebacks(e.g., post-transaction payments from merchants, or acquiring/merchantbanks, back to the issuer to return proceeds from transactions) areappropriate. In the process flow 120, multi-account transaction data 122may represent data associated with the financial transactions involvingthe accounts of a number (e.g., thousands) of credit or debitcardholders. The multi-account transaction data 122 may includeinformation such as transaction dates, transaction amounts, merchantnames (and/or aliases) associated with the transaction, informationrelating to how the card information was collected by the merchant(e.g., by swiping, an EMV chip reader, manual entry of the card number,etc.), geographic locations of “card present” transactions, and so on.The multi-account transaction data 122 may include data obtained (e.g.,by external data collection unit 42 of FIG. 1 ) from merchant computingsystems 22 and/or from acquiring/merchant banks associated with thosemerchants, for example.

Similar to the labels described above in connection with multi-accountdata 82 of process flow 80, the multi-account transaction data 122 maybe associated with multiple chargeback outcome labels. For example, eachlabel may be associated with a data set that includes the correspondingportion of multi-account transaction data 122. The outcome labels mayinclude final chargeback determinations that were made (in connectionwith the transactions represented in multi-account transaction data 122)via earlier iterations of the process flow 120, and/or external to theprocess flow 120. Multi-account transaction data 122 may include many(e.g., thousands) of positively and negatively labeled data sets.

At a process stage 124, the multi-account transaction data 122 may beanalyzed to generate chargeback candidate detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 124 may serve to identify which type(s) of transaction data is/areprobative of whether, under the full chargeback rules of the cardnetwork entity, a chargeback is appropriate for a given transaction.Process stage 124 may also determine the transaction data values and/orcombinations that are probative of whether a chargeback is appropriatefor the transaction.

At a process stage 126, the rules generated or updated at process stage124 may be applied to first account transaction data 130 to determinewhether a transaction associated with the first account is a “good”chargeback candidate. Put differently, process stage 126 may, instead ofapplying the full chargeback rules of the card network entity (which maybe quite lengthy and complex) to the facts surrounding the transaction,use various factors and algorithms developed at process stage 124 todetermine whether there exists a relatively high probability that achargeback would be appropriate for the transaction if the fullchargeback rules were applied. The process stage 126 may calculate apercentage probability that the transaction is one in which a chargebackis appropriate, for example.

The first account transaction data 130 may be associated with theaccount of a particular cardholder or cardholders, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account transaction data130 may depend upon which types of transaction-related data weredetermined, by process stage 124, to be relevant to a chargebackcandidate determination. For example, the first account transaction data130 may include information obtained (e.g., by external data collectionunit 42) from one of merchant computing systems 22 (e.g., the computingsystem of the merchant involved in the transaction being analyzed)and/or from an acquiring/merchant bank associated with that merchant.The first account transaction data 130 may also include informationabout one or more other transactions associated with the first account(e.g., data pertaining to other transactions occurring shortly beforeand/or after the transaction at issue). Some specific examples of rulesthat may be generated by process stage 124, and applied at process stage126, are described below in connection with FIG. 4B.

Process stage 126 may output information indicating whether theparticular transaction represented by first account transaction data 130is a “good” candidate for chargeback detection. For example, processstage 126 may output a percentage probability, calculated according tothe rules generated or updated at process stage 124, that thetransaction is one in which a chargeback is appropriate. As anotherexample, process stage 126 may output a binary indicator of whether thetransaction is, or is not, a strong/likely chargeback candidate (e.g.,by comparing the percentage probability to a threshold probability).

If the transaction is identified as a chargeback candidate at processstage 126, the full chargeback rules of the card network entity may beapplied at a process stage 132. Process stage 132 may include manualapplication of the full chargeback rules, and/or automated applicationof the full chargeback rules, in various different embodiments. Basedupon the analysis at process stage 132, a final chargeback determinationmay be made at a process stage 134. The final determination made atprocess stage 134, along with the first account transaction data 130(and any other data) used to make that determination, may be fed backinto process stage 124 to provide additional labeled data for purposesof updating the rules. In some embodiments, the indication of whetherthe transaction is a good chargeback candidate generated at processstage 126 may also be fed back into process stage 124, to allow themachine learning program to determine and improve upon pastperformance/accuracy.

C. Exemplary Process Flow for Machine Learning of Fraud ClassificationRules

Referring now to FIG. 3C, an exemplary process flow 140 may generally beused to classify instances of suspected or potential fraud. For example,the process flow 140 may represent ongoing, real-time or batchprocessing of a large amount of data associated with a large number ofpotential and/or existing financial accounts (e.g., all accountsassociated with a particular bank, or all accounts opting in to a fraudprotection program, etc.). In this manner, the process flow 140 may beused to initially flag situations for closer investigation, and provideone or more classifications of the type(s) of fraud potentially at issuein order to narrow or otherwise facilitate the investigation. In otherembodiments, the process flow 140 may be used to provide a narrowerclassification (e.g., “skimming”) when a broader class of fraud (e.g.,credit card fraud) is already suspected.

In the process flow 140, multi-account data 142 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. The financial accounts may be existing or potentialaccounts, and the account holders may include holders of accounts and/orpotential holders of potential accounts. For example, the multi-accountdata 142 may include existing and/or applied-for credit card accounts,debit card accounts, savings accounts, checking accounts, investmentaccounts, loan accounts, etc.

Depending upon the embodiment, the multi-account data 142 may includeone or more different types of information obtained (e.g., by externaldata collection unit 42 of FIG. 1) from one or more of FAMS 14,cardholder computing devices 20, merchant computing systems 22, and/orother sources 24. For example, the multi-account data 142 may includetransaction data (e.g., transaction dates, amounts, locations, etc.)from account records database 30 of FAMS 14, data indicative of IPaddresses of cardholder computing devices 20 and/or devices in merchantcomputing systems 22, Internet browsing and/or search history data fromcardholder computing devices 20 (or from an ISP computer system includedin other sources 24, etc.), vehicle telematics data from telematicssystems of cardholder vehicles, home occupancy and/or usage data (e.g.,smart appliance data) from smart home systems of cardholders, and/or oneor more other types of data. Some or all data within multi-account data142 may be information that account holders or potential account holdershave expressly consented to share with an entity associated with FAMS 14and/or AFSS 12 (e.g., in exchange for fraud protection services).

The multi-account data 142 may be associated with multiple frauddetermination labels, each indicating a type or class of fraud (e.g.,“counterfeiting,” “lost or stolen card use,” “skimming,” “chargebackfraud,” “application fraud,” etc.), or indicating a lack of fraud, forexample. In one embodiment, each of a number of data sets in themulti-account data 142 is associated with at least one suchclassification/label, and includes data relating to a particularfinancial transaction, financial account, loan application, etc., forwhich the fraud classification or classifications was/were made (e.g.,after a previous iteration of process flow 140, or after another manualand/or automated fraud investigation). Multi-account data 142 mayinclude many (e.g., thousands) of data sets labeled with various knownfraud classifications.

At a process stage 144, the multi-account data 142 may be analyzed togenerate fraud classification rules (e.g., to be stored in ML rulesdatabase 58). As described above in connection with process stage 84 ofprocess flow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 144 may serveto identify which type(s) of transaction data is/are probative of theparticular type of fraud (if any) that has occurred. Process stage 144may also determine the data values and/or combinations that areprobative of the particular type of fraud (if any) that has occurred.

At a process stage 146, the rules generated or updated at process stage144 may be applied to first account data 150. The first account data 150may be associated with a particular account and a particular customer(e.g., a cardholder associated with a particular one of computingdevices 20). The types of data included in first account data 150 maydepend upon which types of data were determined, by process stage 144,to be relevant to fraud classification. For example, the first accountdata 150 may include information obtained (e.g., by external datacollection unit 42) from one or more of FAMS 14, one of cardholdercomputing devices 20 (i.e., the device associated with the customerholding or applying for the first account), one or more of merchantcomputing systems 22, and/or one or more of other sources 24. Somespecific examples of rules that may be generated by process stage 144,and applied at process stage 146, are described below in connection withFIG. 4C.

Process stage 146 may output data (e.g., a message or code) that is usedto classify suspected fraudulent activity (in connection with theaccount associated with first account data 150) at a process stage 152.For example, process stage 152 may assign a classification of“counterfeiting” if process stage 146 determined that the first accountdata 150 indicated a number of circumstances that, according to therules generated at process stage 144, are known to be correlated withcounterfeiting activity (e.g., two “card present” transactions occurringin different states within the same one-hour time period, etc.). In someembodiments and/or scenarios, two or more classifications mayconcurrently be assigned to first account data 150. For example, processstage 146 may determine a set of probabilities for a set of two or morepotential types of fraud, and process stage 152 may assign eachclassification, with each respective probability, to first account data150. Moreover, in some embodiments and scenarios, process stage 152 mayassign a classification that corresponds to an absence of any suspectedfraud (e.g., “no fraud”).

At a process stage 154, if process stage 152 assigned a classificationother than one indicating the absence of suspected fraud, the firstaccount data 150, and/or other information associated with the accountand the suspected class of fraud, may be analyzed in depth to make afinal fraud determination at a process stage 156. Generally, the fraudclassification may be used to facilitate the analysis at process stage154, with process stage 154 including manual and/or automated frauddetection techniques. For example, personnel associated with AFSS 12 mayuse the fraud classification(s) to inform their strategy and/or focuswith respect to conducting an in-depth fraud investigation.

The additional analysis at process stage 154 may then result in a finalfraud determination at process stage 156. The final determination mayindicate both whether fraud occurred and, if so, the class(es)/type(s)of fraud that occurred. The final determination made at process stage156, and information used to make that determination (e.g., the firstaccount data 150 and potentially other data), may be fed back intoprocess stage 144 to provide additional labeled data for purposes ofupdating the rules. In some embodiments, the (preliminary) fraudclassification made at process stage 152 may also be fed back intoprocess stage 144 to help the machine learning program identifyinstances in which the preliminary classifications at process stage 152were incorrect. Process stage 144 may then update the fraudclassification rules in ways that seek to prevent or reduce suchinstances in the future.

D. Exemplary Process Flow for Machine Learning of Application FraudDetection Rules

Referring now to FIG. 3D, an exemplary process flow 160 may generally beused to detect application fraud. “Application fraud” may generallyrefer to fraud in connection with the application for any type offinancial account, loan and/or line of credit (e.g., mortgage loan,vehicle loan, small business loan, payday loan, home equity line ofcredit, credit card account, debit card account, checking account,savings account, investment account, etc.). In some embodiments and/orscenarios, however, the application may be for non-financial purposes,such as an application for membership in a particular group orinstitution, for example.

In the process flow 160, multi-applicant search history data 162 mayrepresent data associated with the Internet search history of a number(e.g., thousands) of applicants. The multi-applicant search history data162 may include search terms entered by the applicants using onlinesearch engine tools, for example, and/or the results of such searches(e.g., URLs, titles and/or contents of search results), for example.

The multi-applicant search history data 162 may include data obtained(e.g., by external data collection unit 42 of FIG. 1 ) from cardholdercomputing devices 20, from one or more ISPs of other sources 24, and/orfrom a third party aggregator of such information, for example. In someembodiments, the multi-applicant search history data 162 only includesdata that the applicants have expressly consented to share with anentity associated with FAMS 14 and/or AFSS 12 (e.g., in exchange forconsideration of their applications).

As described above in connection with multi-account data 82 of processflow 80, the multi-applicant search history data 162 may be associatedwith multiple fraud determination labels. In some embodiments, eachlabel may be associated with a data set that corresponds to anapplication submitted by a particular applicant, where the data setincludes the corresponding portion of multi-applicant search historydata 162 (e.g., the search terms and/or results associated with theparticular application). The labels may include final frauddeterminations that were made via earlier iterations of the process flow160, and/or external to the process flow 160. Multi-applicant searchhistory data 162 may include many (e.g., thousands) of positively andnegatively labeled data sets.

At a process stage 164, the multi-applicant search history data 162 maybe analyzed to generate application fraud detection rules (e.g., to bestored in ML rules database 58). As described above in connection withprocess stage 84 of process flow 80, any suitable type of supervisedmachine learning program/technique(s) may be used. Generally, processstage 164 may serve to identify which type(s) of Internet search-relateddata is/are probative of whether application fraud has occurred, and todetermine the data values and/or combinations that are probative ofwhether application fraud has occurred.

At process stage 166, the rules generated or updated at process stage164 may be applied to first applicant search history data 170. The firstapplicant search history data 170 may be associated with a particularapplication and a particular applicant (e.g., a person associated with aparticular one of computing devices 20), for example. The types of dataincluded in first applicant search history data 170 may depend uponwhich types of Internet search-related data were determined, by processstage 164, to be relevant to a fraud determination. The first applicantsearch history data 170 may include information obtained (e.g., byexternal data collection unit 42) from one of computing devices 20(i.e., the device associated with the first applicant), and/or from anISP of other sources 24, for example. Some specific examples of rulesthat may be generated by process stage 164, and applied at process stage166, are described below in connection with FIG. 4D.

Process stage 166 may output information indicating whether fraud issuspected in connection with the application corresponding to firstapplicant search history data 170. For example, process stage 166 mayoutput a percentage probability, calculated according to the rulesgenerated or updated at process stage 164, that the application wasfraudulently made (e.g., by someone other than the purported applicantor an authorized representative thereof). As another example, processstage 166 may output a binary indicator of whether the applicationlikely was, or likely was not, fraudulently made (e.g., by comparing apercentage probability to a threshold probability).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) is performed at anadditional stage, shown in dashed lines in FIG. 3D as process stage 172.The additional analysis may then be used to make a final frauddetermination (e.g., a final decision on whether application fraudoccurred) at process stage 174. In other embodiments, process stage 172is omitted from process flow 160, and process stage 174 merelyrepresents the output of process stage 166. The final determination madeat process stage 174, along with the first applicant search history data170 (and any other data) used to make that determination, may be fedback into process stage 164 to provide additional labeled data forpurposes of updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 166 is also fed back into processstage 164, to allow the machine learning program to determine andimprove upon past performance/accuracy.

E. Exemplary Process Flow for Machine Learning of Fraud DisputeResolution Rules

Referring now to FIG. 3E, an exemplary process flow 180 may generally beused to facilitate the resolution of fraud disputes (or potentialdisputes) with customers/account holders. For example, the process flow180 may be used to determine whether a reportedly unauthorized orfraudulent transaction (e.g., one that the account holder reported assuch when looking at his or her account statement) was indeedunauthorized or fraudulent. In some embodiments, the process flow 180may also, or instead, be used to determine whether an “unrecognized”transaction (i.e., one that the account holder does not recall, but doesnot necessarily report as fraudulent) was unauthorized or fraudulent.

In the process flow 180, multi-account data 182 may represent dataassociated with financial accounts of a number (e.g., thousands) ofaccount holders. For example, the multi-account data 182 may includedata associated with financial transactions relating to credit cardaccounts, debit card accounts, savings accounts, checking accounts, etc.For ease of explanation, FIG. 3E will be described with reference to anembodiment in which the accounts are credit card accounts.

In one embodiment, the multi-account data 182 may include transactiondata (e.g., transaction dates, amounts, locations, etc.) obtained fromFAMS 14 (e.g., by external data collection unit 42 of FIG. 1 ). In someembodiments, however, the multi-account data 182 also includesinformation obtained from cardholder computing devices 20, merchantcomputing systems 22, and/or other sources 24. For example, themulti-account data 182 may include, in addition to transaction data fromaccount records database 30 of FAMS 14, data indicative of IP addressesof cardholder computing devices 20 and/or devices in merchant computingsystems 22, Internet browsing and/or search history data from cardholdercomputing devices 20 (or from an ISP computer system included in othersources 24, etc.), vehicle telematics data from telematics systems ofcardholder vehicles, home occupancy and/or usage data (e.g., smartappliance data) from smart home systems of cardholders, autonomousvehicle data, smart vehicle data, mobile device data, vehicle or mobiledevice GPS data, and/or one or more other types of data. Some or alldata within multi-account data 182 may be information that accountholders or potential account holders have expressly consented to sharewith an entity associated with FAMS 14 and/or AFSS 12 (e.g., in exchangefor fraud protection services).

As described above in connection with multi-account data 82 of processflow 80, the multi-account data 182 may be associated with multiplefraud determination labels (e.g., “fraud” and “no fraud,” and/or morecomplex labels that indicate type/class, such as “lost/stolen card use,”etc.). In some embodiments, each label may be associated with a data setthat includes the corresponding portion of multi-account data 182. Thelabels may include final fraud determinations that were made via earlieriterations of the process flow 180, and/or external to the process flow180. Multi-account data 182 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 184, the multi-account data 182 may be analyzed togenerate query generation rules (e.g., to be stored in ML rules database58). As described above in connection with process stage 84 of processflow 80, any suitable type of supervised machine learningprogram/technique(s) may be used. Generally, process stage 184 may serveto identify which types of information are probative of whether fraudhas occurred, and to craft rules that formulate queries to ascertainsuch information based upon account data.

For example, process stage 184 may determine that, for a suspect “cardpresent” transaction, a verified, non-fraudulent “card present”transaction within 10 miles and 3 hours of the suspect transaction isprobative of whether the suspect transaction was fraudulent. Based uponthis finding, process stage 184 may also generate a rule specifying thata cardholder should be queried as to whether he/she can confirm makingeach “card present” transaction within 10 miles and 3 hours of thesuspect transaction. As another example, process stage 184 may determinethat a merchant using a billing alias different from its legal and/orcommonly-known name (e.g., by at least some threshold level ofsimilarity, as measured by number of similar characters, order ofcharacters, etc.) is probative of whether the cardholder authorized atransaction associated with that billing alias. Based upon this finding,process stage 184 may generate a rule specifying that a cardholdershould be queried as to whether he/she is aware of a billing alias usedfor a suspect transaction if that billing alias is sufficientlydifferent from the legal/common name of the merchant.

At process stage 186, the rules generated or updated at process stage184 may be applied to first account data 190. The first account data 190may be associated with a particular cardholder, such as a cardholderassociated with a particular one of cardholder computing devices 20, forexample. The types of data included in first account data 190 may dependupon which types of data were determined, by process stage 184, to berelevant to developing dispute resolution queries. Process stage 186 maygenerate a set of one or more queries in accordance with the rules andthe contents of first account data. Some specific examples of rules thatmay be generated by process stage 184 and applied at process stage 186,and the queries that may be generated as a result, are described belowin connection with FIG. 4E.

At a process stage 192, the generated queries may be sent to thecardholder in one or more of various ways, such as sending the queriesvia SMS text message and/or email, and/or via a web browser or dedicatedapplication executing on the one of cardholder computing devices 20 thatis associated with the cardholder, for example. At a process stage 194,responses to the queries are received from the cardholder (e.g., viainputs made by the cardholder via the web browser or application, or aresponsive SMS text message or email, etc.). In some embodiments, therules generated or updated at process stage 184 specify the manner inwhich follow-up queries should be generated based upon the responsesreceived at process stage 194, and process stages 192 and 194 may berepeated multiple times.

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) that makes use ofthe received responses is performed at an additional stage, shown indashed lines in FIG. 3E as process stage 196. The additional analysismay then be used to make a final fraud determination (e.g., a finaldecision on whether fraud occurred, and/or on the type of fraud thatoccurred) at process stage 198. In other embodiments, process stage 196is omitted from process flow 180, and process stage 198 is based uponinformation from the cardholder. For example, the questions generated atprocess stage 192 may “jog” the cardholder's memory, and cause him orher to indicate that the transaction at issue was authorized. The finaldetermination made at process stage 198, along with the first accountdata 110 (and any other data used at process stage 196), the queriesgenerated at process stage 186 and/or the responses received at processstage 194, may be fed back into process stage 184 to provide additionallabeled data for purposes of updating the rules.

F. Exemplary Process Flow for Machine Learning of Document FraudDetection Rules

Referring now to FIG. 3F, an exemplary process flow 200 may generally beused to detect fraud relating to documents, such as counterfeit and/orforged documents. The process flow 200 may be used in connection withvarious kinds of documents, such as checks (e.g., personal checks,cashier's checks, etc.), money orders, treasury bills, identificationdocuments (e.g., social security cards, driver's licenses, passports,birth certificates, etc.), certification documents, and so on.

In the process flow 200, multi-document image data 202 may representdigital images of a number (e.g., thousands) of physical documents ofone or more types. The multi-document image data 202 may include imagesin one or more formats, such as raster formats (e.g., JPEG, TIFF, GIF,BMP, PNG, etc.) and/or vector formats (e.g., CGM, SVG, etc.), forexample. The multi-document image data 202 may include data obtained(e.g., by external data collection unit 42 of FIG. 1 ) from merchantcomputing systems 22 (e.g., point-of-sale devices with cameras fordocument identification) and/or from FAMS 14 (e.g., images of personalchecks), for example. In some embodiments, the multi-document image data202 may only include data representing images that customers (or otherindividuals associated with the documents) have expressly consented toshare (e.g., as a prerequisite to making a purchase, or in exchange forfraud protection services, etc.).

As described above in connection with multi-account data 82 of processflow 80, the multi-document image data 202 may be associated withmultiple fraud determination labels. In some embodiments, each label maybe associated with data representing a digital image of a particulardocument. The labels may include final fraud determinations (e.g.,“fraud” or “no fraud,” or more complex labels such as “forgery,”“counterfeit,” “forgery—signature,” “counterfeit—angular line offset(s)outside tolerance,” etc.) that were made via earlier iterations of theprocess flow 200, and/or external to the process flow 200.Multi-document image data 202 may include many (e.g., thousands) ofpositively and negatively labeled data sets.

At a process stage 204, the multi-document image data 202 may beanalyzed to generate document fraud detection rules (e.g., to be storedin ML rules database 58). As described above in connection with processstage 84 of process flow 80, any suitable type of supervised machinelearning program/technique(s) may be used. Generally, process stage 204may serve to identify which characteristics of a document are probativeof whether the document is counterfeit, and to determine the ranges,tolerances, etc., that are probative of whether the document iscounterfeit. In some embodiments, process stage 204 also, or instead,identifies which characteristics of information entered in documentfields are probative of whether the document was forged (e.g., draftedor populated by someone other than the person purported to have draftedor populated the document).

At process stage 206, the rules generated or updated at process stage204 may be applied to first document image data 210. The first documentimage data 210 may be digital image data corresponding to a particular,physical document. The first document image data 210 may includeinformation obtained (e.g., by external data collection unit 42) fromone of merchant computing systems 22 (e.g., for real-time verificationof an identification or other document presented during or prior to asale), or from FAMS 14 (e.g., for real-time or batch-processingverification of a personal check prior to clearing the check), forexample. Some specific examples of rules that may be generated byprocess stage 204, and applied at process stage 206, are described belowin connection with FIG. 4F.

Process stage 206 may output information indicating whether fraud issuspected in connection with the document corresponding to firstdocument image data 210. For example, process stage 206 may output twopercentage probabilities calculated according to the rules generated orupdated at process stage 204, with the first indicating the likelihoodthat the document is counterfeit and the second indicating thelikelihood that the document includes forged content. As anotherexample, process stage 206 may output binary indicators of whether thedocument likely is, or likely is not, counterfeit and/or includes forgedcontent (e.g., by comparing percentage probabilities to thresholdprobabilities).

In some embodiments, further analysis (e.g., a manual review, or furtherautomated review using additional data sources, etc.) may be performedat a process stage 212. The additional analysis may then be used to makea final fraud determination (e.g., a final decision on whether thedocument is fraudulent) at process stage 214. For example, the processstage 206 may act as a filter, and flag only those documents having arelatively high probability of being fraudulent. In this manner, aconsiderably smaller amount of human and/or processing resources may beconsumed at process stage 212.

The final determination made at process stage 214, along with the firstdocument image data 210 used to make that determination, may be fed backinto process stage 204 to provide additional labeled data for purposesof updating the rules. In some embodiments, a preliminary frauddetermination made at process stage 206 may also be fed back intoprocess stage 204, to allow the machine learning program to determineand improve upon past performance/accuracy.

IV. Exemplary Rules for Fraud Detection and/or Classification

FIGS. 4A-4F depict exemplary factors and algorithms that may be used inconnection with various fraud detection and/or classification rules,according to different embodiments. It is noted that the rule setscorresponding to FIGS. 4A-4F are purely for purposes of illustration andare not limiting. Particularly in embodiments where machine learning isutilized, for example, the algorithms and/or factors may be far morecomplex, and/or less intuitive, than some or all of the examples shownin FIGS. 4A-4F.

A. Exemplary Fraud Detection Rule Set Using Online Activity

Referring first to FIG. 4A, an exemplary rule set 220 (e.g., generatedat process stage 104 of FIG. 3A) may use various factors relating toonline activity of a cardholder to detect fraud in connection with aparticular credit or debit card transaction. The rule set 220 maycorrespond to a particular embodiment and scenario in which thetransaction at issue is a “card present” transaction, and in which therule set 220 seeks to determine whether the cardholder made or otherwiseauthorized the transaction. The rule set 220 may be incorporated into areview process that is generally applied to all transactions, a reviewprocess applied only to those transactions that were flagged by apreliminary fraud alert, or a review process applied only after acardholder reports the transaction as unauthorized, for example.

The factors considered under the rule set 220 may include a number ofinterest-based factors 222 and a number of location-based factors 224.The interest-based factors 222 may relate to the cardholder's interest(or non-interest) in a product or service purchased via the transaction,and/or the merchant providing the product or service, while thelocation-based factors 224 may relate to the cardholder's location orprobable location.

As seen in FIG. 4A, the interest-based factors 222 may include: (1)whether the cardholder searched online for the specific product orservice purchased via the transaction at issue (e.g., by determiningwhether search terms entered by the cardholder included the name of theproduct or service involved in the transaction, or included adescription of the product or service, etc.); (2) whether the cardholdervisited a website associated with the merchant (e.g., by comparing URLsof websites visited by the cardholder to a known URL of the merchant'swebsite, or by searching the contents of websites visited by thecardholder for the merchant's name, etc.); (3) whether the cardholderendorsed the merchant, or the product or service provided by themerchant, via a social media account of the cardholder (e.g., bydetermining whether the cardholder “liked” the merchant, product orservice via his or her Facebook® account, etc.); (4) whether thecardholder visited a website associated with a competitor of themerchant (e.g., by comparing URLs of web sites visited by the cardholderto known URLs of known competitors' websites, or by searching thecontents of websites visited by the cardholder for the competitors'names, etc.); (5) whether the cardholder searched online for a differentproduct or service in the same price range as the transaction amount(e.g., by analyzing search terms and/or results, and/or by analyzingURLs or contents of websites visited by the cardholder and comparingprices of products/services, etc.); and/or (6) whether the cardholderentered search terms indicative of the cardholder's need for the productor service (e.g., by determining that the cardholder entered searchterms including “pipe leak” prior to the purchase of new plumbinghardware, or “computer repair” prior to the purchase of a new harddrive, etc.). In other embodiments, the interest-based factors 222 mayinclude more, fewer and/or different factors than those shown in FIG.4A.

As is also seen in FIG. 4A, the location-based factors 224 may include:(1) whether the cardholder “checked in” to a flight having a destinationnear the location where the transaction was initiated (e.g., bydetermining whether the cardholder checked in to a flight having adestination at the city in which the transaction occurred, or within athreshold number of miles of the city in which the transaction occurred,etc.); (2) whether the cardholder visited a website associated with aplace near (or in) which the transaction was initiated (e.g., bycomparing URLs of websites visited by the cardholder to URLs of websitesknown to be associated with particular areas, and/or by searching thecontents of websites visited by the cardholder for location or areanames, etc.); and/or (3) whether the cardholder endorsed a place near(or in) which the transaction was initiated via a social media accountof the cardholder (e.g., by determining whether the cardholder “liked”the geographic area, attraction or other place via his or her Facebook®account, etc.). In other embodiments, the location-based factors 224 mayinclude more, fewer and/or different factors than those shown in FIG.4A.

Generally, the data indicative of whether the circumstance correspondingto each of interest-based factors 222 and/or location-based factors 224is present/true for a particular cardholder may be included in the firstcustomer online activity data 110 described above in connection withFIG. 3A. For example, external data collection unit 42 of FIG. 1 mayobtain the search terms, URLs, user online selections, etc., needed todetermine whether the various factors exist, from the cardholder'scomputing device (e.g., one of cardholder computing devices 20) and/orfrom an ISP of other sources 24.

As is also seen in FIG. 4A, each of the interest-based factors 222 andlocation-based factors 224 may be associated with a particular score orweighting value. In the rule set 220 shown in FIG. 4A, a total score maybe calculated based upon which factors are, or are not, present (e.g.,add 94 points if it is determined that the cardholder searched for theparticular lawnmower model that was purchased, add another 80 points ifthe transaction was a “card present” transaction in the Chicago suburbof Joliet and the cardholder checked in to a flight to Chicago justprior to the transaction, etc.).

In some embodiments, certain factors may instead be associated withnegative scores (e.g., minus 80 if the cardholder checked in to a flightwith a destination at least 200 miles from the site of the transactionand within one day of the transaction, etc.). Moreover, certain factorsmay be associated with metrics or algorithms that determine how heavilythose factors are weighed. As indicated in FIG. 4A, for example, searchterms entered by the cardholder may be used to calculate a “need score”X (e.g., where X is based upon frequency of certain search terms beingused, the amount of time spent clicking through search results, themagnitude and/or urgency of a problem indicated by the search terms,etc.), with X then being used to calculate a score equal to 0.2X.

The rule set 220 may then output the total score (e.g., 94+80=+174), anormalized total score, an indication of whether the total scoreexceeded a threshold (e.g., a threshold of +100), a probabilitycalculated based upon the total score, and/or some other indicator ormeasure of the existence or likelihood of fraud. In the example shown inFIG. 4A, it can be seen that larger scores generally correspond to agreater probability that the transaction was made or authorized by thecardholder. If the transaction is being automatically reviewed (e.g., todetermine whether a fraud alert is appropriate, without any initialinput from the cardholder), this may mean that a lower score correspondsto a higher probability of fraud. Conversely, if the cardholder hadreported the transaction as being fraudulent, a higher score maycorrespond to a higher probability of fraud (i.e., fraud on the part ofthe cardholder).

In some embodiments, the rule set 220 may also include one or more othertypes of factors not necessarily based upon online activities of thecardholder (e.g., whether GPS of the cardholder's smartphone or vehicleindicates that he or she was in that area shortly before or after thetransaction, etc.), and/or may omit either interest-based factors 222 orlocation-based factors 224.

B. Exemplary Chargeback Candidate Detection Rule Set

Referring next to FIG. 4B, an exemplary rule set 230 (e.g., generated atprocess stage 124 of FIG. 3B) may use various factors relating to atransaction between a cardholder and a merchant to determine whether thetransaction should be flagged as a candidate for a chargeback (e.g., todetermine whether the transaction should be reviewed under a full set ofchargeback rules associated with the appropriate card network entity).The rule set 230 may correspond to a particular embodiment and scenarioin which the transaction at issue is a “card present” transaction.

As seen in FIG. 4B, the factors considered under the rule set 230 mayinclude: (1) whether an EMV chip card was not inserted in apoint-of-sale EMV chip reader device of the merchant; (2) whether anon-EMV card was not swiped in a point-of-sale device of the merchant;(3) whether the card is past its expiration date; (4) whether thetransaction is for the same amount and/or date as another transactioninvolving the same card and merchant (e.g., by analyzing othertransactions involving the same account and merchant within a particulartime span); and/or (2) whether the transaction is for greater than athreshold amount. For example, one of merchant computing systems 22 ofFIG. 1 (or an acquiring/merchant bank) may provide transaction detailsthat include the amounts, dates, etc., to FAMS 14 for storage in accountrecords database 30, and external data collection unit 42 may thenretrieve that information from account records database 30. Generally,the data indicative of whether the circumstance corresponding to each ofthe factors is present/true for a particular transaction may be includedin the first account transaction data 130 described above in connectionwith FIG. 3B. In other embodiments, the factors considered under ruleset 230 may include more, fewer and/or different factors than thoseshown in FIG. 4B. It is noted that, in some embodiments, one or morefactors may simply relate to the desirability (e.g., from a card issuerperspective) of further reviewing whether a chargeback is appropriate,without necessarily relating to the likelihood that a chargeback isappropriate.

As is also seen in FIG. 4B, each of the factors may be associated with aparticular score or weighting value. A total score may be calculatedbased upon which factors are, or are not, present (e.g., add 62 pointsif it is determined that the transaction has the same amount and date asanother transaction occurring close in time and involving the same cardand merchant). In some embodiments, certain factors may instead beassociated with negative scores, and/or certain factors may beassociated with metrics or algorithms that determine how heavily thosefactors are weighed.

The rule set 230 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that a chargeback is appropriatefor the transaction. In the example shown in FIG. 4B, it can be seenthat larger scores generally correspond to a greater probability that achargeback is appropriate.

C. Exemplary Fraud Classification Rule Set

Referring now to FIG. 4C, an exemplary rule set 240 (e.g., generated atprocess stage 144 of FIG. 3C) may use a diverse array of factors toclassify the type(s) of fraudulent activity, if any, that is/aresuspected to be associated with an event or series of events. The ruleset 240 may correspond to a particular embodiment and scenario in whichthe event at issue is a financial transaction involving a debit orcredit card. In other embodiments and/or scenarios, however, the ruleset 240 may classify fraudulent activity with respect to specific othertypes of events (e.g., loan applications), or may detect a variety ofdifferent event types (e.g., various types of financial transactions,loan or credit applications, etc.) and broadly classify fraudulentactivity in connection with the detected event types (e.g., lost/stolencard use, application fraud, etc.).

In one embodiment, each potential classification (with the possibleexception of “no fraud”) may be associated with a number of factorsprobative of whether that type/class of fraud has occurred. As seen inFIG. 4C, for example, the rule set 240 may include counterfeit factors242 (e.g., factors indicating that a counterfeit card was used for thetransaction), account takeover factors 244 (e.g., factors indicatingthat the transaction resulted from an unauthorized person gaining onlineaccess to the credit or debit card account itself, via phishing, malwareor other means), chargeback fraud factors 246 (e.g., factors indicatingthat the cardholder made or otherwise authorized a purchase that thecardholder later contested) and skimming factors 248 (e.g., factorsindicating that the card information used for the transaction wasobtained via a skimming card reader device illegally installed in anATM, gas station pump or other location). In other embodiments, the ruleset 240 may also, or instead, include factors corresponding to one ormore other fraud classifications (e.g., forgery, lost/stolen card use,etc.).

As seen in FIG. 4C, the counterfeit factors 242 may include: (1) whetherthe suspect transaction and another, contemporaneous transaction (e.g.,occurring within one hour, etc.) in another state are both “cardpresent” transactions; and/or (2) if the suspect transaction is a “cardpresent” transaction, whether the card (if an EMV chip card) was notinserted in an EMV chip card reader. For example, one or more ofmerchant computing systems 22 of FIG. 1 (or one or moreacquiring/merchant banks) may provide transaction details that includewhether the transaction was “card present,” whether the card wasinserted in an EMV chip card reader, etc., to FAMS 14 for storage inaccount records database 30, and external data collection unit 42 maythen retrieve that information from account records database 30. Inother embodiments, the counterfeit factors 242 may include more, fewerand/or different factors than those shown in FIG. 4C.

The account takeover factors 244 may include: (1) whether the debit orcredit card account password was changed within the 10 days prior to thetransaction; and/or (2) whether the transaction was originated from anIP address not associated with the cardholder. For example, externaldata collection unit 42 may retrieve password change information fromaccount records database 30 of FIG. 1 , which may log all passwordupdate activity, and/or may retrieve IP address information from one ofmerchant computing systems 22 (e.g., the computing system of themerchant involved in the transaction). In other embodiments, the accounttakeover factors 244 may include more, fewer and/or different factorsthan those shown in FIG. 4C.

The chargeback fraud factors 246 may include: (1) whether the cardholderhad searched online for the product or service purchased via thetransaction; and/or (2) whether the cardholder had visited a websiteassociated with the merchant involved in the transaction. For example,external data collection unit 42 of FIG. 1 may retrieve online searchinformation (e.g., search terms and/or results) and/or URLs from the oneof cardholder computing devices 20 that is associated with thecardholder, and/or from an ISP (of other sources 24) used by thecardholder. In other embodiments, the chargeback fraud factors 246 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

The skimming factors 248 may include: (1) the number (X) of earliertransactions in which the card used for the transaction at issue wasused at an ATM machine or a gas station pump within the 10 days prior tothe transaction at issue; and/or (2) whether the transaction at issueoriginated from an IP address not associated with the cardholder. Forexample, external data collection unit 42 of FIG. 1 may retrievetransaction data indicating that certain past purchases were made usinggas station pump card readers, and/or indicating that the card was usedfor one or more ATM withdrawals, from account records database 30,and/or may retrieve the originating IP address from the one of merchantcomputing systems 22 associated with the merchant involved in thetransaction at issue. In other embodiments, the skimming factors 248 mayinclude more, fewer and/or different factors than those shown in FIG.4C.

Generally, the data indicative of whether the circumstance correspondingto each of counterfeit factors 242, account takeover factors 244,chargeback fraud factors 246 and/or skimming factors 248 is present/truefor a particular transaction may be included in the first account data150 described above in connection with FIG. 3C, for example.

As is also seen in FIG. 4C, each of the counterfeit factors 242, accounttakeover factors 244, chargeback fraud factors 246 and skimming factors248 may be associated with a particular score or weighting value. Thefactors for each classification (counterfeit, account takeover,chargeback fraud, skimming) may be used to calculate a total scorespecific to that classification. In the rule set 240 shown in FIG. 4C,for example, a counterfeit score may be calculated based upon which offactors 242 are, or are not, present, an account takeover score may becalculated based upon which of factors 244 are, or are not, present, andso on. In some embodiments, certain factors may instead be associatedwith negative scores, and/or certain factors (e.g., the first ofskimming factors 248 shown in FIG. 4C) may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

For each classification/category, the rule set 240 may output the totalscore, a normalized total score, an indication of whether the totalscore exceeded a threshold, a probability calculated based upon thetotal score, and/or some other indicator or measure of the likelihoodthat fraud of that particular type/class occurred in connection with thetransaction. In the example shown in FIG. 4C, it can be seen that largerscores generally correspond to a greater probability that the respectiveclassification is accurate. Referring back to FIG. 3C, theclassification at process stage 152 may be the classification having thehighest score and/or probability under rule set 240, or may include thescore and/or probability for each classification, the top threeclassifications, etc.

D. Exemplary Application Fraud Detection Rule Set

Referring now to FIG. 4D, an exemplary rule set 260 may use onlinesearch information (e.g., search terms, search results, clicked/selectedsearch results, etc.) to detect whether an application was fraudulent(e.g., not populated and/or submitted by the purported applicant). Therule set 260 may have been generated at process stage 164 of FIG. 3D,for example. The rule set 260 may be incorporated into a review processthat is generally applied to all applications received by a particularentity or anti-fraud service, or a review process applied only to thoseapplications that were flagged by a preliminary fraud alert, forexample.

The factors considered under the rule set 260 may generally be probativeof whether the person that submitted the application (e.g., via a webbrowser, a dedicated application, as an email attachment, by snail mail,etc.) had performed one or more online searches indicating that he orshe was trying to learn more about the purported applicant in order topopulate particular fields of the application (e.g., a “home address”field, “employment history” fields, etc.). The “purported applicant” maybe a person whose name appears in a name and/or signature field of theapplication, for example.

As seen in FIG. 4D, the factors of exemplary rule set 260 may include:(1) whether the applicant used search terms that included the name ofthe purported applicant; (2) whether the search terms also included thewords “address” or “residence” (and possibly other synonyms ornear-synonyms); and/or (3) whether the search terms also included thewords “employer,” “job” and/or “career” (and possibly other synonyms ornear-synonyms). In other embodiments, the rule set 260 may include more,fewer and/or different factors than those shown in FIG. 4D. For example,the rule set 260 may include one or more factors relating to whichsearch results appeared and/or were selected (e.g., “clicked” on afterappearing on a user interface) by the applicant.

Generally, the data indicative of whether the circumstancescorresponding to the factors of rule set 260 are present/true for aparticular applicant may be included in the first applicant searchhistory data 170 described above in connection with FIG. 3D. Forexample, external data collection unit 42 of FIG. 1 may obtain thesearch terms, search results, search result user selections, etc.,needed to determine whether the various factors exist, from theapplicant's computing device (e.g., similar to one of cardholdercomputing devices 20) and/or from an ISP of other sources 24. Access tosuch information may be made a condition of having the application beconsidered, for example.

As is also seen in FIG. 4D, each of the factors of rule set 260 may beassociated with a particular score or weighting value. A total score maythen be calculated based upon which factors are, or are not, present. Insome embodiments, certain factors may instead be associated withnegative scores, and/or certain factors may be associated with metricsor algorithms that determine how heavily those factors are weighed.

The rule set 260 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the existence or likelihood of applicationfraud. In the example shown in FIG. 4D, it can be seen that largerscores may generally correspond to a greater probability that theapplication was not populated and/or submitted by the purportedapplicant.

E. Exemplary Fraud Dispute Resolution Rule Set

Referring now to FIG. 4E, a flow diagram illustrates at least a portionof a process flow 270 implementing an exemplary rule set for frauddispute, or potential fraud dispute, resolution (e.g., a rule setgenerated at process stage 184 of FIG. 3E). The process flow 270 may beused to help resolve a dispute over a contested transaction, or to helpa customer recall an unrecognized transaction, for example. FIG. 4Eillustrates a process flow, rather than just a set of factors, in orderto better illustrate an example process for generating queries basedupon the generated rules, according to one embodiment. The process flow270 may correspond to a particular embodiment and scenario in which thetransaction subject to dispute or potential dispute is a credit or debitcard transaction.

In the exemplary process flow 270, the rule set may specify that aprocess stage 272 determines whether the transaction was a “cardpresent” transaction. If not, the rule set may specify that the flowproceed directly to a process stage 280. If so, however, the rule setmay specify that the flow instead proceeds to a process stage 274.

The rule set may also specify that process stage 274 determines whetherat least one other transaction associated with the cardholder's accountoccurred within some threshold number of hours (X) of the transaction atissue. If not, the rule set may specify that the flow proceeds directlyto process stage 280. If so, however, the rule set may specify that theflow instead proceeds to a process stage 276.

Process stage 276 may generate one or more location-related queriesusing transaction data associated with the cardholder's account. Thequeries may ask, for example, whether the cardholder was in (or near)one or more particular geographic areas or locations at various times.If the transaction at issue occurred in San Francisco, for example, witha first other “card present” transaction occurring in Santa Rosa fourhours earlier and a second other “card present” transaction occurring inSan Jose two hours later, process stage 276 may generate one or morequeries asking whether the cardholder made or authorized the earlierand/or later transactions, and/or whether the cardholder traveled on aroute from Santa Rosa to San Jose that passed through San Francisco,etc.

In some embodiments, the location-related queries are generated basedupon data associated with events or circumstances other thantransactions. For example, if the transaction at issue occurred inSarasota, Florida, and the data considered under the rule set indicatesthat the cardholder checked in to a flight to Tampa, process stage 276may generate one or more queries asking whether the cardholder completedthe flight, where the cardholder went after landing in Tampa, etc.

The rule set may also specify that process stage 280 determines whetherthe transaction at issue is associated with a billing alias that isdissimilar to the name of the merchant involved in the transaction. Forexample, the computing system of the merchant (e.g., one of merchantcomputing systems 22 of FIG. 1 ) may have sent to FAMS 14 a transactionrecord that identified the merchant by the alias, and was presented tothe cardholder as an online or paper account statement. Thedetermination at process stage 280 may use the billing alias to identifya legal and/or common name of the merchant (e.g., using a relationaldatabase stored in AFSS12 or FAMS 14), and determine that there is atleast some threshold level of dissimilarity (e.g., based upon differenceof characters, character ordering, etc.) between the billing alias andthe merchant name.

If the billing alias and merchant name are not sufficiently dissimilar,the rule set may specify that the flow proceeds directly to a processstage 284. If sufficiently dissimilar, however, the rule set may specifythat the flow instead proceeds to a process stage 282. Process stage 282may generate a query relating to the billing alias that was presented tothe cardholder. For example, the query may ask whether the cardholder isaware that the billing alias is used by that particular merchant. Insome embodiments, process stage 282 may instead generate a message thatsimply informs the cardholder that the billing alias corresponds to themerchant, without posing a question.

The rule set may specify that process stage 284 generates one or moredefault queries. For example, one default query may ask whether thecardholder lent his or her card to a friend or family member around thetime of the transaction. In some embodiments and/or scenarios, processstage 284 may be omitted from process flow 270. Generally, the queries(and possibly non-query messages) generated in process flow 270 mayserve to help the cardholder recall whether the transaction was made orauthorized, and/or process flow 270 may prompt the cardholder forresponses that are considered by others (e.g., personnel of an entityassociated with FAMS 14 of FIG. 1 ) to determine whether the transactionwas likely fraudulent.

Although not shown in FIG. 4E, in some embodiments process flow 270 mayinclude a number of iterative stages in which responses are receivedfrom the cardholder (e.g., from the respective one of cardholdercomputing devices 20 in FIG. 1 ) and used to generate additional, moredetailed questions for the cardholder. For example, if a first queryasks whether the cardholder recalls personally making another “cardpresent” transaction that occurred at a nearby time and place, and thecardholder responds “no,” a new query may be generated asking whetherthe cardholder recalls personally making the next closest transaction(in terms of time and/or location).

F. Exemplary Document Fraud Detection Rule Set

Referring next to FIG. 4F, an exemplary rule set 290 (e.g., generated atprocess stage 204 of FIG. 3F) may use various factors relating to animaged (e.g., photographed or scanned) physical document to determinewhether the document should be flagged as a candidate for a morein-depth (e.g., manual) analysis/review for fraud purposes. The rule set290 may correspond to a particular embodiment and scenario in which thedocument is one that includes at least a signature field (e.g., apersonal check, a driver's license, etc.).

The factors considered under the rule set 290 may include a number ofcounterfeit factors 292 and a number of forgery factors 294, each ofwhich may be evaluated by image analysis unit 52 of FIG. 1 using one ormore image processing techniques. The counterfeit factors 292 may relateto the look, presentation, format and/or structure of the document,while the forgery factors 294 may relate to the substance, style orformat of information entered in one or more fields of the document.

As seen in FIG. 4F, the counterfeit factors 292 may include: (1) whetherone or more absolute or relative dimensions and/or angles of thedocument, or of lines, illustrations, patterns, etc. shown on thedocument (excluding user-entered contents in fields such as thesignature line), are outside one or more predetermined tolerances; (2)whether one or more colors on the document are outside a predeterminedtolerance (e.g., color/frequency range); (3) whether one or more linethicknesses of the document (excluding user-entered field contents) areoutside one or more predetermined tolerances; and/or (4) whether one ormore fonts on the document (excluding user-entered field contents) areoutside one or more predetermined tolerances. For example, imageanalysis unit 52 may determine whether the ratio of the document lengthto the document width is within 0.1% of an expected value. As anotherexample, image analysis unit 52 may determine whether horizontal andvertical lines on the document are within 0.3 degrees of the horizontaland vertical edges of the document, respectively. As yet anotherexample, image analysis unit 52 may determine whether a font used for afield descriptor or other text on the document matches an expected font(e.g., by meeting a similarity threshold measured in any suitablemanner). In other embodiments, the counterfeit factors 292 may includemore, fewer and/or different factors than those shown in FIG. 4F.

The forgery factors 294 may include: (1) whether a signature entered ina signature field of the document match is outside a predeterminedtolerance (e.g., using any suitable signature recognition technique);(2) whether handwriting entered in one or more fields of the document isoutside a predetermined tolerance (e.g., by applying a suitablehandwriting recognition technique); and/or (3) whether the format ofinformation entered by a user in one or more fields does not match anexpected format (e.g., using “9.12.16” rather than the expected“9/12/2016,” as established based upon other documents known to havebeen populated and/or submitted by the purported applicant). In otherembodiments, the forgery factors 294 may include more, fewer and/ordifferent factors than those shown in FIG. 4F.

Generally, the data indicative of whether the circumstancescorresponding to counterfeit factors 292 and/or forgery factors 294 arepresent/true for a particular document may be included in the firstdocument image data 210 described above in connection with FIG. 3F.

As is also seen in FIG. 4F, each of the counterfeit factors 292 andforgery factors 294 may be associated with a particular score orweighting value. In the rule set 290 shown in FIG. 4F, a total score maybe calculated based upon which factors are, or are not, present. In someembodiments, certain factors may instead be associated with negativescores, and/or certain factors may be associated with metrics oralgorithms that determine how heavily those factors are weighed.

The rule set 290 may then output the total score, a normalized totalscore, an indication of whether the total score exceeded a threshold, aprobability calculated based upon the total score, and/or some otherindicator or measure of the likelihood that the document is fraudulent.Alternatively, the rule set 290 may output a separate total score,normalized score, probability, or other metric, for each of counterfeitfactors 292 and forgery factors 294, with the counterfeit metricindicating the likelihood that the document is a counterfeit and theforgery metric indicating the likelihood that the document wasfraudulently populated by someone other than the purported person (e.g.,by someone other than the person corresponding to the name, signature,address, etc. on the document). In the example shown in FIG. 4F, it canbe seen that larger scores generally correspond to a greater probabilitythat the document is fraudulent. In some embodiments, the rule set 290also includes one or more other types of factors not shown in FIG. 4F,and/or omits either counterfeit factors 292 or forgery factors 294.

V. Exemplary Methods for Fraud Detection & Classification

FIGS. 5-11 depict flow diagrams of various exemplarycomputer-implemented methods that may be implemented by one or morecomponents of AFSS 12 of FIG. 1 . In one embodiment, AFSS 12 implementsall of the methods corresponding to FIGS. 5-11 . In other embodiments,AFSS 12 implements only a subset (e.g., one, two, etc.) of the methodscorresponding to FIGS. 5-11 . Each of the methods described below may beimplemented by fraud detection/classification unit 36 of FIG. 1 , forexample.

A. Exemplary Methods for Detecting Chargeback Candidates and/orCompromised Merchants

Referring now to FIG. 5 , an exemplary computer-implemented method 300may be used to identify a potential chargeback scenario, e.g., to narrowdown the field of fraudulent transactions that should be furtherinvestigated for chargeback purposes. In the method 300, chargebackcandidate detection rules may be generated or updated (block 301). Therules may be generated or updated using a machine learning program, suchas any of the types of machine learning programs discussed above inconnection with ML rule generator 40 of FIG. 1 or process stage 84 ofFIG. 2 , for example. The machine learning program may be trained usingtransaction data associated with a plurality of financial transactions,and chargeback determinations each corresponding to a respective one ofthe plurality of financial transactions. The chargeback determinations(e.g., indications of whether a chargeback was or was not instituted foreach transaction) may each be made in accordance with chargeback rulesassociated with (e.g., provided by) a card network entity.

An indication that fraud has been confirmed for a first financialtransaction, associated with a particular financial account and aparticular merchant, may be received (block 302). For example, anautomated investigation (e.g., using any suitable process, method ortechnique described herein), and/or a manual investigation, may havebeen performed to determine that the first financial transaction wasfraudulent in some way, and a user input or other data indicative ofthat outcome may be received at block 302.

First transaction data, associated with the first financial transaction,may be retrieved (block 303). For example, a database containing accountrecords (e.g., account records database of FIG. 1 ) may contain a recordof transactions associated with each of multiple accounts, and thetransaction of interest may be retrieved at block 303 by accessing theinformation stored in the database.

It may be determined, by applying the chargeback candidate detectionrules generated or updated at block 301 to the first transaction dataretrieved at block 303, that a chargeback may be warranted for the firstfinancial transaction (block 304). For example, the first financialtransaction may be flagged as a relatively strong candidate with respectto the appropriateness of a chargeback payment from the merchant oracquiring bank to the card issuer. In other scenarios, not representedby FIG. 5 , it may instead be determined that a chargeback is not a goodchargeback candidate.

The determination at block 304 may be based upon different factors, inaccordance with the specific scenario and/or embodiment. For example,the determination may be based at least upon a card associated with thefinancial account being expired when the first financial transactionoccurred. As other examples, the determination may be based at leastupon a dollar amount of the first financial transaction (e.g., theamount exceeding a threshold), and/or upon a second financialtransaction under the same account duplicating one or morecharacteristics of the first financial transaction (e.g., the sameamount, date, time, and/or other characteristics that may be indicativeof an improper duplicate charge).

An indication that the chargeback may be warranted may be caused to bedisplayed to one or more people via one or more respective computingdevice user interfaces (block 305). The indication may also specify thetransaction at issue, the merchant, and possibly other information suchas the transaction date, amount, etc. The indication may be sent to acomputing device of a card issuer or other entity, for example, toprompt a full review of the first financial transaction under thechargeback rules of the card network entity. Block 305 may beimplemented by notification unit 56 of FIG. 1 , for example.

In some embodiments, the method 300 may include one or more additionalblocks not shown in FIG. 5 . For example, the method 300 may include anadditional block in which it is determined, by applying the chargebackrules of the card network entity to the first transaction data andadditional data associated with that transaction (e.g., additional datareceived from the merchant and/or other sources), that a chargeback isindeed warranted for the transaction. The additional data may includedata indicative of a card information entry mode used to conduct thefirst financial transaction (e.g., “card present,” swiped, inserted inan EMV chip card reader, etc.), for example. In other embodiments and/orscenarios, the chargeback rules may be applied manually.

As another example, the method 300 may include an additional block inwhich first account data associated with the first financial account isretrieved (e.g., card expiration date, whether the card is an EMV card,etc., possibly obtained from the same account records database accessedat block 303). In such an embodiment, block 304 may further includeapplying the chargeback candidate detection rules to the first accountdata.

FIG. 6 illustrates an exemplary computer-implemented method 310 ofdetermining that a merchant computer terminal warrants a chargebackafter a consumer dispute or fraudulent transaction based upon disputerules (or chargeback rules). The method 310 may include, via one or moreprocessors and/or transceivers, determining a merchant and/or a merchantcomputing terminal associated with a fraudulent financial transaction,such as by IP address (block 311). The method 310 may include, the oneor more processors and/or transceivers, retrieving a configuration, orparameters or specifications of the merchant computing terminal from amemory unit, or receiving such information via wireless communication ordata transmission over one or more radio links or wireless communicationchannel transmitted by the merchant computing terminal (block 312). Themethod 310 may include retrieving, via the one or more processors and/ortransceivers, current or up-to-date dispute rules regarding computerspecifications or requirements (block 313). The method 310 may includecomparing, via the one or more processors, the current dispute rulesregarding computer requirements with the merchant computer terminalspecifications to determine whether or not the merchant computerterminal is compliant with current dispute rules (block 314). Forinstance, the one or more processors may analyze the dispute rules toidentify requirements or required specifications of merchant computingterminals. The method 310 may include verifying other dispute rules aresatisfied for a valid chargeback and/or whether the financialtransaction is still within requisite time or allowable recovery period.The method 310 may include, if the merchant computer terminal is notcompliant with the dispute rules or computer required specifications,generating an electronic chargeback notification and transmitting it toa merchant computing device (block 315) to facilitate merchantnotification.

For instance, the dispute rules may require merchant computing terminalsto be equipped with “chip” readers, smart card readers, or the like. Themethod 310 may determine that the merchant computing terminal is onlyequipped with older or “swipe” technology, and if so, a card issuer maybe entitled to a chargeback associated with a fraudulent transactionfrom the merchant.

In one aspect, a computer-implemented method of identifying a merchantcomputer terminal warranting a chargeback may be provided. The methodmay include (1) identifying, via one or more processors and/ortransceivers, a merchant computer terminal (and/or an IP address of themerchant computer terminal) associated with a fraudulent financialtransaction; (2) retrieving or receiving, via the one or more processorsand/or transceivers, an actual configuration, parameters, and/orspecifications associated with the merchant computer terminal; (3)retrieving or receiving, via the one or more processors and/ortransceivers, up-to-date dispute rules associated with chargebacks, thedispute rules including merchant computer terminal requirements; (4)analyzing, via the one or more processors, the dispute rules todetermine merchant computer terminal requirements; (5) comparing, viathe one or more processors and/or transceivers, the merchant computerterminal requirements from the current dispute rules with the actualconfiguration, parameters, and/or specifications associated with themerchant computer terminal to identify if the merchant computer terminalis non-complaint with the dispute rules; (6) if the merchant computerterminal is non-complaint, then generating, via the one or moreprocessors, an electronic notification that includes an identificationof the financial transaction at issue, a transaction amount, and that achargeback is warranted due to a merchant computing device beingnon-compliant with the dispute rules; and/or (7) transmitting, via theone or more processors and/or transceivers, the electronic notificationto a merchant computing device via wireless communication over one ormore radio frequency links to facilitating resolving financialtransaction disputes.

The method may include receiving, via the one or more processors and/ortransceivers, dispute rules associated with a credit card issuer; andidentifying, via the one or more processors, merchant computer terminaltechnical specifications that would warrant a chargeback and merchantcomputer terminal technical specifications that would not warrant achargeback.

The method may include receiving, via the one or more processors and/ortransceivers, actual technical specifications of a merchant computerassociated with the financial transaction; comparing, via the one ormore processors, the actual technical specifications with the merchantcomputer terminal technical specifications that would warrant achargeback to determine that a chargeback is warranted; and/orgenerating, via the one or more processors, an electronic notificationindicating that the chargeback is warranted.

The method may include receiving, via the one or more processors and/ortransceivers, actual technical specifications of a merchant computerassociated with the financial transaction; comparing, via the one ormore processors, the actual technical specifications with the merchantcomputer terminal technical specifications that would not warrant achargeback (or satisfy computer requirements of the dispute rules) todetermine that a chargeback is not warranted; and/or generating, via theone or more processors, an electronic notification indicating that thechargeback is not warranted based upon computer specifications.

In another aspect, a computer system configured to identify a merchantcomputer terminal warranting a chargeback may be provided. The computersystem may include one or more processors and/or transceivers configuredto: identify a merchant computer terminal (and/or an IP address of themerchant computer terminal) associated with a fraudulent financialtransaction; retrieve from a local or remote memory unit, and/or receivevia wireless communication or data transmission over one or more radiolinks or wireless communication channels, an actual configuration,parameters, and/or specifications associated with the merchant computerterminal; retrieve from a local or remote memory unit, and/or receivevia wireless communication or data transmission over one or more radiolinks or wireless communication channels, up-to-date dispute rulesassociated with chargebacks, the dispute rules including merchantcomputer terminal requirements; determine merchant computer terminalrequirements from processor analysis of the dispute rules; compare themerchant computer terminal requirements from the current dispute ruleswith the actual configuration, parameters, and/or specificationsassociated with the merchant computer terminal to identify if themerchant computer terminal is non-complaint with the dispute rules; ifthe merchant computer terminal is non-complaint, then generate anelectronic notification that includes an identification of the financialtransaction at issue, a transaction amount, and that a chargeback iswarranted due to a merchant computing device being non-compliant withthe dispute rules; and/or transmit the electronic notification to amerchant computing device via wireless communication or datatransmission over one or more radio frequency links or wirelesscommunication links to facilitating resolving financial transactiondisputes.

FIG. 7 illustrates a computer-implemented method 320 of identifyingcompromised, or potentially compromised, merchants and/or reducingfuture chargebacks (or actual losses) or fraud. The method 320 mayinclude, via one or more processors and/or transceivers (such as viawireless communication or data transmission over one or more radiofrequency links and/or wireless communication channels), (1) generatinga list of chargebacks for a given period of time (block 321); (2)inputting the list of chargebacks associated with the merchant (and/orassociated facts related to the underlying financial transaction) into amachine learning program that is trained to identify a reason why eachchargeback was generated (or actual loss was incurred), and/or a type orclassification of each chargeback (block 322) (such stolen card, lostcard, account take over, fraudulent application, compromised computingsystem, identity theft, counterfeit card, etc.); (3) analyzing thereason and/or the type or classification of each chargeback to identifythose chargebacks associated with a potentially compromised merchantcomputer system (block 323) (such as by inputting the reason and/or thetype or classification of each chargeback into a second machine learningprogram trained to identify chargebacks associated with potentiallycompromised merchant computer systems); (4) determining a merchantassociated with a number of chargebacks within the given period of time(including those that are identified as being associated withpotentially compromised merchant computer systems) that are over apredetermined threshold amount or an outlier amount indicative ofsuspicious activity (block 324), such as a spike in a specific type orclassification of chargeback that is an individual merchant isexperiencing; (5) generating an electronic notification notifying thepotentially compromised merchant of a possibility of a data breach orother security concern (block 325); and/or (6) transmitting theelectronic notification to a compromised merchant computing device(block 326) to alert the compromised merchant of the data breach orother security concern.

FIG. 8 illustrates a computer-implemented method 330 of identifyingcompromised, or potentially compromised, merchants. The method 330 mayinclude, via one or more processors and/or transceivers (such as viawireless communication or data transmission over one or more radiofrequency links and/or wireless communication channels), (1) generatingfinancial fraud electronic alerts using a rules-based model or engine(block 331); (2) inputting the financial fraud electronic alerts into amachine learning program trained to determine a reason why each fraudalert was generated (such stolen card, lost card, account take over,fraudulent application, compromised computing system, identity theft,counterfeit card, etc.), and/or a type or classification of each fraudalert (block 332); (3) analyzing the reason and/or the type orclassification of each fraud alert to identify those fraud alertsassociated with a potentially compromised merchant computer system(block 333) (such as by inputting the reason and/or the type orclassification of each fraud alert into a second machine learningprogram trained to identify fraud alerts associated with potentiallycompromised merchant computer systems or determine unusual fraud alertsfor individual merchants or types of merchants); (4) determining amerchant associated with a number of fraud alerts (such as thoseidentified as being associated with potentially compromised merchantcomputer systems, or other types of alerts) that are over apredetermined threshold or an outlier amount indicative of suspiciousactivity (block 334); (5) generating an electronic notificationnotifying the compromised merchant of a possibility of a data breach orother security concern (block 335); and/or (6) transmitting theelectronic notification to a compromised merchant computing device(block 336) to alert the compromised, or potentially compromised,merchant of the data breach or other security concern.

H. Exemplary Application Fraud Detection Methods

Referring now to FIG. 9 , an exemplary computer-implemented method 340may be used to detect potential application fraud, e.g., to detectinstances where an applicant for a loan, credit, checking, savings,investment and/or other type of account, service or benefit is not theperson that he or she purports to be. In the method 340, applicationdata, indicative of applicant entries in one or more fields of anapplication associated with a potential account, may be received (block341). The application may be an application received from a sourcecomputing device via the Internet (e.g., via a web page, via a dedicatedapplication, via email, etc.), for example.

The source computing device, via which the applicant submitted theapplication data, may be identified (block 342). The source computingdevice may be similar to one of computing devices 20 of FIG. 1 , forexample. In one embodiment, block 342 may include identifying an IPaddress of the source computing device.

Search history data, indicative of one or more search terms submitted toan Internet-based search engine (e.g., a Google® or Yahoo® searchengine) via the source computing device, may be retrieved (block 343).The search history data may be retrieved from a database maintained byan ISP of the applicant, or a temporary database that is locallyconstructed based upon information received directly from the sourcecomputing device, for example. In one embodiment where the IP address ofthe source computing device is identified at block 342, the searchhistory data may include search terms that were submitted to theInternet-based search engine from the identified IP address.

It may be determined, by analyzing the application data and the searchhistory data, that the applicant may not be the person whom theapplicant purports to be (block 344), e.g., the person whose name and/orsignature is included on the application, or is otherwise listed orindicated in connection with the application. For example, theapplication may be flagged at block 344 for a further, more in-depthreview. In other scenarios, not represented by FIG. 9 , it may insteadbe determined that the applicant likely is the person whom he or shepurports to be, such that it is not necessary to flag the applicationfor further review.

Block 344 may include various operations, depending upon the embodimentand/or scenario. For example, block 344 may include comparinginformation included in retrieved search term(s) (and/or included insearch results) to information included in the applicant entries in theapplication fields. As other examples, block 344 may include comparing aname included in the search term(s) to a name included in the applicantentries, determining that the search term(s) is/are directed todiscovering an address associated with the name (e.g., by including theterms “Jonathon Doe address” or “Jonathon Doe residence,” etc.), and/ordetermining that the search term(s) is/are directed to discovering anemployment history associated with the name (e.g., by including theterms “Jonathon Doe employer” or “Jonathon Doe work history,” etc.).

An indication of potential application fraud may be caused to bedisplayed to one or more people via one or more respective computingdevice user interfaces (block 345). The indication may also specify thepurported applicant, the actual applicant, and/or other relevantinformation. The indication may be sent to a computing device of a cardissuer or other entity, for example, to prompt a full review of theapplication (e.g., a manual investigation). Block 345 may be implementedby notification unit 56 of FIG. 1 , for example.

In some embodiments, the method 340 may include one or more additionalblocks not shown in FIG. 9 . For example, in an embodiment where block344 includes applying application fraud detection rules to theapplication data and the search history data, the method 340 may includean additional block in which the application fraud detection rules aregenerated or updated. For example, the rules may be generated or updatedby training a machine learning program, such as any of the types ofmachine learning programs discussed above in connection with ML rulegenerator 40 of FIG. 1 or process stage 84 of FIG. 2 . The machinelearning program may be trained using historical application frauddeterminations made in connection with a plurality of otherapplications, and additional search history data associated withadditional source computing devices (e.g., the devices that submittedthe data for those applications), for example.

FIG. 10 illustrates an exemplary computer-implemented method 350 ofusing IP address and/or browsing activity to identify fraudulent onlineor virtual applications. The method 350 may include, via one or moreprocessors and/or transceivers, receiving an online or virtualapplication via wireless communication or data transmission over one ormore radio links or wireless communication channels (block 351), such asan application for financial services, such as vehicle, home, orpersonal loans, or credit cards. The virtual application may include anIP address identification and/or a recent browser activity history ofthe computer. The method 350 may include determining or retrieving aname of the applicant listed on the online application (block 352). Themethod 350 may include determining an IP address of the source computerthat generated the online application (block 353). The method 350 mayinclude retrieving or receiving recent online browsing activity of thesource computer (such as by using the IP address and/or browsingactivity received with the virtual application, or querying the sourcecomputer for such information) (block 354). The method 350 may includedetermining if the recent online activity of the source computerincludes internet searches on the applicant's name and/or theapplicant's social media presence or website (block 355) (indicatingthat the person submitting the application retrieved facts about thenamed applicant in an effort to perform fraudulent activity orimpersonate the named applicant). If so, the method 350 may includeflagging the virtual application as fraudulent, and/or in need offurther manual or processor review (block 356).

In one aspect, a computer-implemented method of using browsing activityto identify fraudulent online or virtual applications may be provided.The method may include (1) receiving, via one or more processors and/ortransceivers, a virtual application over one or more radio frequencylinks or wireless communication channels; (2) determining, via the oneor more processors, an applicant name on the virtual application; (3)determining, via the one or more processors, an IP address of a sourcecomputer from which the virtual application originated; (4) determiningor receiving, via the one or more processors and/or transceivers, anonline browsing or search history associated with the IP address and/orsource computer; (5) determining, via the one or more processors, if theonline browsing or search history indicates recent internet searches foror on the applicant name; and/or (6) if so, flagging, via the one ormore processors, the virtual application as fraudulent and generating anelectronic alert indicating that the virtual application is fraudulentto facilitating identifying fraudulent virtual or online applicationsfor goods or services.

The virtual application may include a field or routine that records andretrieves recent online browsing or searching activity of the sourcecomputer, and that information is transmitted from the source computeralong with the virtual application when the virtual application issubmitted. In other words the virtual application may carry with itonline browsing or search activity associated with the source computerwhen it is transmitted or submitted to a remote server, such as afinancial services provider remote server.

The virtual application may include a field or routine that records andretrieves recent social media searching activity of the source computer.The virtual application may include a field or routine that records andretrieves recent internet search engine searching activity of the sourcecomputer. The virtual application may include an IP address field of thesource computer. The virtual application may include a current GPSlocation of the source computer.

The method may further include determining, via the one or moreprocessors, whether the named applicant is an existing customer; if so,receiving, via the one or more processors, customer data from one ormore sources indicating a current customer location; determining, viathe one or more processors, whether the current customer locationcorresponds to, or is within a predetermined distance of, a location ofthe source computer from which the virtual application originated;and/or if the current customer location does not correspond to thelocation of the source computer, then generating, via the one or moreprocessors, an electronic alert indicating such.

Determining an online browsing or search history associated with the IPaddress and/or source computer may include retrieving an online browsingor search history stored with or within the virtual application.Receiving an online browsing or search history associated with the IPaddress and/or source computer may include receiving, via the one ormore processors and/or transceivers, an online browsing or searchhistory over one or more radio links or wireless communication channelsvia wireless communication or data transmission. The virtual or onlineapplication may be an application for financial services or products,such vehicle, home, or personal loans; a credit card application; or anapplication for auto, homeowners, or life insurance.

In another aspect, a computer system configured to use IP addressesand/or browsing activity to identify fraudulent online or virtualapplications may be provided. The computer system may include one ormore processors and/or transceiver configured to: receive a virtualapplication via wireless communication or data transmission over one ormore radio frequency links or wireless communication channels; determinean applicant name on the virtual application (or retrieve the virtualapplicant name saved within the virtual application); determine an IPaddress of a source computer from which the virtual applicationoriginated; determine or receive an online browsing or search historyassociated with the IP address and/or source computer; determine if theonline browsing or search history indicates recent internet searchesfor, or on, the applicant name; and/or if so, flag the virtualapplication as fraudulent and generate an electronic alert indicatingthat the virtual application is fraudulent to facilitating identifyingfraudulent virtual or online applications for goods or services.

FIG. 11 illustrates a computer-implemented method 360 of identifyingmortgage fraud. The method 360 may include, via one or more processorsand/or transceivers (such as via wireless communication or datatransmission over one or more radio frequency links or wirelesscommunication channels), (1) receiving a virtual application for a homeloan or line of credit for a property and an identity of a person orentity applying (block 361); (2) receiving home loan or line of creditinformation for the property from multiple sources or lenders, each ofthe multiple sources or lenders having provided a previous home loan orline of credit for the property (block 362), such as providing aprevious home loan or line of credit for the property to the person orentity applying for another home loan or line of credit; (3) retrievingfrom a memory, or receiving an appraisal for the property, the appraisalincluding an estimated or actual value of the property (block 363), suchas receiving a virtual appraisal from another lender; (4) determiningthat a total amount of the multiple home loans or lines of credit forthe property exceed the estimated or actual value of the property, or apercentage thereof (block 364); (5) if so, generating an electronicnotification indicating that mortgage fraud associated with the propertymay exist and/or denying the application (block 365); and/or (6)transmitting the electronic notification to the multiple sources orlenders to notify them of the potential mortgage fraud (block 366).

VI. Exemplary System for Fraud Detection & Classification

FIG. 12 depicts an exemplary computer system 500 in which the techniquesdescribed herein may be implemented, according to one embodiment. Thecomputer system 500 of FIG. 12 may include a computing device in theform of a computer 510. Components of the computer 510 may include, butare not limited to, a processing unit 520, a system memory 530, and asystem bus 521 that couples various system components including thesystem memory 530 to the processing unit 520. The system bus 521 may beany of several types of bus structures including a memory bus or memorycontroller, a peripheral bus, or a local bus, and may use any suitablebus architecture. By way of example, and not limitation, sucharchitectures include the Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus (also known as Mezzanine bus).

Computer 510 may include a variety of computer-readable media.Computer-readable media may be any available media that can be accessedby computer 510 and may include both volatile and nonvolatile media, andboth removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media may include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media may include, but is not limited to, RAM, ROM, EEPROM,FLASH memory or other memory technology, CD-ROM, digital versatile disks(DVD) or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canaccessed by computer 510.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism, and mayinclude any information delivery media. The term “modulated data signal”means a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in the signal. By wayof example, and not limitation, communication media may include wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, radio frequency (RF), infrared and otherwireless media. Combinations of any of the above are also includedwithin the scope of computer-readable media.

The system memory 530 may include computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 531and random access memory (RAM) 532. A basic input/output system 533(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 510, such as during start-up, istypically stored in ROM 531. RAM 532 typically contains data and/orprogram modules that are immediately accessible to, and/or presentlybeing operated on, by processing unit 520. By way of example, and notlimitation, FIG. 12 illustrates operating system 534, applicationprograms 535, other program modules 536, and program data 537.

The computer 510 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 12 illustrates a hard disk drive 541 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 551that reads from or writes to a removable, nonvolatile magnetic disk 552,and an optical disk drive 555 that reads from or writes to a removable,nonvolatile optical disk 556 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 541 may be connected to thesystem bus 521 through a non-removable memory interface such asinterface 540, and magnetic disk drive 551 and optical disk drive 555may be connected to the system bus 521 by a removable memory interface,such as interface 550.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 12 provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 510. In FIG. 12 , for example, hard disk drive 541 isillustrated as storing operating system 544, application programs 545,other program modules 546, and program data 547. Note that thesecomponents can either be the same as or different from operating system534, application programs 535, other program modules 536, and programdata 537. Operating system 544, application programs 545, other programmodules 546, and program data 547 are given different numbers here toillustrate that, at a minimum, they are different copies. A user mayenter commands and information into the computer 510 through inputdevices such as cursor control device 561 (e.g., a mouse, trackball,touch pad, etc.) and keyboard 562. A monitor 591 or other type ofdisplay device is also connected to the system bus 521 via an interface,such as a video interface 590. In addition to the monitor, computers mayalso include other peripheral output devices such as printer 596, whichmay be connected through an output peripheral interface 595.

The computer 510 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer580. The remote computer 580 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andmay include many or all of the elements described above relative to thecomputer 510, although only a memory storage device 581 has beenillustrated in FIG. 12 . The logical connections depicted in FIG. 12include a local area network (LAN) 571 and a wide area network (WAN)573, but may also include other networks. Such networking environmentsare commonplace in hospitals, offices, enterprise-wide computernetworks, intranets and the Internet.

When used in a LAN networking environment, the computer 510 is connectedto the LAN 571 through a network interface or adapter 570. When used ina WAN networking environment, the computer 510 may include a modem 572or other means for establishing communications over the WAN 573, such asthe Internet. The modem 572, which may be internal or external, may beconnected to the system bus 521 via the input interface 560, or otherappropriate mechanism. The communications connections 570, 572, whichallow the device to communicate with other devices, are an example ofcommunication media, as discussed above. In a networked environment,program modules depicted relative to the computer 510, or portionsthereof, may be stored in the remote memory storage device 581. By wayof example, and not limitation, FIG. 12 illustrates remote applicationprograms 585 as residing on memory device 581.

The techniques for detecting and/or classifying fraud described abovemay be implemented in part or in their entirety within a computer systemsuch as the computer system 500 illustrated in FIG. 12 . The computer510 may be included in AFSS 12 of FIG. 1 , for example, and/or theremote application programs 585 may include one or more applications ofeither FAMS 14, one of cardholder computing device 20, one of merchantcomputing systems 22, or a computing device of other sources 24.Moreover, the functionality of fraud detection/classification unit 36 ofFIG. 1 may be implemented by one or more of application programs 535and/or other program modules 536. As another example, ML rules database58, account holder behaviors database 60 and/or chargeback rulesdatabase 62 of FIG. 1 may be stored in hard disk drive 541 (e.g., asprogram data 547), magnetic disk 552 and/or optical disk drive 555,and/or the data retrieved by fraud detection/classification unit 36 ofFIG. 1 may be stored in hard disk drive 541 (e.g., as program data 547)and/or RAM 532 (e.g., as program data 537).

VII. Exemplary Method Embodiments

In another aspect, a computer-implemented method, implemented in one ormore servers or other computing devices, of identifying a potentialchargeback scenario may include (1) generating or updating, by one ormore processors of the one or more servers, chargeback candidatedetection rules, at least by training a machine learning program usingat least (i) transaction data associated with a plurality of financialtransactions, and (ii) chargeback determinations each made in accordancewith chargeback rules associated with a card network entity, and eachcorresponding to a respective one of the plurality of financialtransactions; (2) receiving, by the one or more processors, anindication that fraud has been confirmed for a first financialtransaction associated with a merchant and a first financial account;(3) retrieving, by the one or more processors and from an accountrecords database, first transaction data associated with the firstfinancial transaction; (4) determining, by the one or more processorsapplying the chargeback candidate detection rules to the firsttransaction data, that a chargeback may be warranted for the firstfinancial transaction; and/or (5) causing, by the one or moreprocessors, an indication that the chargeback may be warranted to bedisplayed to one or more people via one or more respective computingdevice user interfaces, wherein the indication may further specifying atleast the first financial transaction and the merchant. The method mayinclude additional, fewer or alternative actions, such as any of thosediscussed elsewhere herein.

For instance, the method may further include determining, by the one ormore processors applying the chargeback rules to (i) the firsttransaction data and (ii) additional data associated with the firstfinancial transaction, that a chargeback is warranted for the firstfinancial transaction.

Additionally or alternatively, the method may further include, prior todetermining that the chargeback is warranted, receiving at least aportion of the additional data from the merchant. Additionally oralternatively, the portion of the additional data received from themerchant may include data indicative of a card information entry modeused to conduct the first financial transaction.

Additionally or alternatively, the method may further includeretrieving, by the one or more processors and from the account recordsdatabase, first account data associated with the first financialaccount, and determining that the chargeback may be warranted for thefirst financial transaction may further be performed by the one or moreprocessors applying the chargeback candidate detection rules to thefirst account data.

Additionally or alternatively, determining that a chargeback may bewarranted for the first financial transaction may include determiningthat a chargeback may be warranted based at least upon a card associatedwith the first financial account being expired when the first financialtransaction occurred. Additionally or alternatively, determining that achargeback may be warranted for the first financial transaction mayinclude determining that a chargeback may be warranted based at leastupon (i) a dollar amount of the first financial transaction, and/or (ii)a second financial transaction duplicating one or more characteristicsof the first financial transaction.

In another aspect, a computer-implemented method, implemented in one ormore servers or other computing devices, of detecting potentialapplication fraud may include (1) receiving, by one or more processorsof the one or more servers, application data indicative of applicantentries in one or more fields of an application associated with apotential account; (2) identifying, by the one or more processors, asource computing device via which the applicant submitted theapplication data; (3) retrieving, by the one or more processors and froma database, search history data indicative of one or more search termssubmitted to an Internet-based search engine via the source computingdevice; (4) determining, by the one or more processors analyzing theapplication data and the search history data, that the applicant may notbe a person whom the applicant purports to be; and/or (5) causing, bythe one or more processors, an indication of potential application fraudto be displayed to one or more people via one or more respectivecomputing device user interfaces. The method may include additional,fewer or alternative actions, such as any of those discussed elsewhereherein.

For instance, identifying the source computing device may includeidentifying an Internet Protocol (IP) address of the source computingdevice. Additionally or alternatively, retrieving search history datamay include retrieving search history data indicative of search termssubmitted to the Internet-based search engine from the identified IPaddress.

Additionally or alternatively, determining that the applicant may not bethe person whom the applicant purports to be may include comparinginformation included in the one or more search terms to informationincluded in the applicant entries in the one or more fields; comparing aname included in the one or more search terms to a name included in theapplicant entries in the one or more fields; determining that theapplicant may not be the person whom the applicant purports to be mayfurther include determining that the one or more search terms aredirected to discovering an address associated with the name; and/ordetermining that the one or more search terms are directed todiscovering an employment history associated with the name.

Additionally or alternatively, (1) determining that the applicant isnot, or may not be, the person whom the applicant purports to be mayinclude determining, by the one or more processors applying applicationfraud detection rules to the application data and the search historydata, that the applicant may not be a person whom the applicant purportsto be; and/or (2) the method may further include generating or updating,by the one or more processors, the application fraud detection rules, atleast by training a machine learning program using at least (i)historical application fraud determinations made in connection with aplurality of applications, and (ii) additional search history dataassociated with a plurality of additional source computing devices.

VIII. Exemplary System Embodiments

In another aspect, a computer system for identifying a potentialchargeback scenario may include (1) an account records databaseconfigured to store data associated with a plurality of financialaccounts; (2) a rules database configured to store chargeback candidatedetection rules; (3) one or more processors; and/or (4) a non-transitorymemory. The non-transitory memory stores instructions that, whenexecuted by the one or more processors, may cause the one or moreprocessors to (1) generate or update the chargeback candidate detectionrules, at least by training a machine learning program using at least(i) transaction data associated with a plurality of financialtransactions stored in the account records database, and (ii) chargebackdeterminations each made in accordance with chargeback rules associatedwith a card network entity, and each corresponding to a respective oneof the plurality of financial transactions; (2) receive an indicationthat fraud has been confirmed for a first financial transactionassociated with a merchant and a first financial account; (3) retrieve,from the account records database, first transaction data associatedwith the first financial transaction; (4) determine, by applying thechargeback candidate detection rules stored in the rules database to thefirst transaction data, that a chargeback may be warranted for the firstfinancial transaction; and/or (5) cause an indication that thechargeback may be warranted to be displayed to one or more people viaone or more respective computing device user interfaces, wherein theindication may further specify at least the first financial transactionand the merchant. The system may include additional, fewer oralternative components, features and/or functionality, such as any ofthose discussed elsewhere herein.

For instance, the instructions may further cause the one or moreprocessors to determine, by applying the chargeback rules to (i) thefirst transaction data and (ii) additional data associated with thefirst financial transaction, that a chargeback is warranted for thefirst financial transaction. Additionally or alternatively, theinstructions may further cause the one or more processors to, prior todetermining that the chargeback is warranted, receive at least a portionof the additional data from the merchant.

Additionally or alternatively, the portion of the additional datareceived from the merchant may include data indicative of a cardinformation entry mode used to conduct the first financial transaction.Additionally or alternatively, the instructions may further cause theone or more processors to retrieve, from the account records database,first account data associated with the first financial account, and/orthe instructions may cause the one or more processors to determine thatthe chargeback may be warranted for the first financial transactionfurther by applying the chargeback candidate detection rules to thefirst account data.

Additionally or alternatively, the instructions may cause the one ormore processors to determine that a chargeback may be warranted for thefirst financial transaction based at least upon a card associated withthe first financial account being expired when the first financialtransaction occurred. Additionally or alternatively, the instructionsmay cause the one or more processors to determine that a chargeback maybe warranted for the first financial transaction based at least upon (i)a dollar amount of the first financial transaction, and/or (ii) a secondfinancial transaction duplicating one or more characteristics of thefirst financial transaction.

In another aspect, a computer system for detecting potential applicationfraud may include (1) a search history database configured to store dataassociated with a plurality of Internet searches; (2) one or moreprocessors; and/or (3) a non-transitory memory. The non-transitorymemory stores instructions that, when executed by the one or moreprocessors, may cause the one or more processors to (1) receiveapplication data indicative of applicant entries in one or more fieldsof an application associated with a potential account; (2) identify asource computing device via which the applicant submitted theapplication data; (3) retrieve, from the search history database, searchhistory data indicative of one or more search terms submitted to anInternet-based search engine via the source computing device; (4)determine, by analyzing the application data and the search historydata, that the applicant may not be a person whom the applicant purportsto be; and/or (5) cause an indication of potential application fraud tobe displayed to one or more people via one or more respective computingdevice user interfaces. The system may include additional, fewer oralternative components, features and/or functionality, such as any ofthose discussed elsewhere herein.

For instance, the instructions may cause the one or more processors toidentify the source computing device at least by identifying an InternetProtocol (IP) address of the source computing device. Additionally oralternatively, the search history data may be indicative of search termssubmitted to the Internet-based search engine from the identified IPaddress.

The instructions may cause the one or more processors to determine thatthe applicant may not be the person whom the applicant purports to be(i) at least by comparing information included in the one or more searchterms to information included in the applicant entries in the one ormore fields; (ii) at least by comparing a name included in the one ormore search terms to a name included in the applicant entries in the oneor more fields; (iii) further by determining that the one or more searchterms are directed to discovering an address associated with the name;and/or (iv) further by determining that the one or more search terms aredirected to discovering an employment history associated with the name.

Additionally or alternatively, (1) the instructions may cause the one ormore processors to determine that the applicant may not be the personwhom the applicant purports to be at least by determining, by applyingapplication fraud detection rules to the application data and the searchhistory data, that the applicant may not be the person whom theapplicant purports to be; and/or (2) the instructions may further causethe one or more processors to generate or update the application frauddetection rules, at least by training a machine learning program usingat least (i) historical application fraud determinations made inconnection with a plurality of applications, and (ii) additional searchhistory data associated with a plurality of additional source computingdevices.

IX. Exemplary Computer-Readable Medium Embodiments

In one aspect, a non-transitory, computer-readable medium storinginstructions that, when executed by one or more processors, may causethe one or more processors to (1) generate or update chargebackcandidate detection rules, at least by training a machine learningprogram using at least (i) transaction data associated with a pluralityof financial transactions, and (ii) chargeback determinations each madein accordance with chargeback rules associated with a card networkentity, and each corresponding to a respective one of the plurality offinancial transactions; (2) receive an indication that fraud has beenconfirmed for a first financial transaction associated with a merchantand a first financial account; (3) retrieve, from an account recordsdatabase, first transaction data associated with the first financialtransaction; (4) determine, by applying the chargeback candidatedetection rules to the first transaction data, that a chargeback may bewarranted for the first financial transaction; and/or (5) cause anindication that the chargeback may be warranted to be displayed to oneor more people via one or more respective computing device userinterfaces, wherein the indication may further specify at least thefirst financial transaction and the merchant. The system may includeadditional, fewer or alternative components, features and/orfunctionality, such as any of those discussed elsewhere herein.

For instance, the instructions may further cause the one or moreprocessors to determine, by applying the chargeback rules to (i) thefirst transaction data and (ii) additional data associated with thefirst financial transaction, that a chargeback is warranted for thefirst financial transaction. Additionally or alternatively, theinstructions may further cause the one or more processors to, prior todetermining that the chargeback is warranted, receive at least a portionof the additional data from the merchant.

Additionally or alternatively, the portion of the additional datareceived from the merchant may include data indicative of a cardinformation entry mode used to conduct the first financial transaction.Additionally or alternatively, the instructions may further cause theone or more processors to retrieve, from the account records database,first account data associated with the first financial account, and/orthe instructions may cause the one or more processors to determine thatthe chargeback may be warranted for the first financial transactionfurther by applying the chargeback candidate detection rules to thefirst account data.

Additionally or alternatively, the instructions may cause the one ormore processors to determine that a chargeback may be warranted for thefirst financial transaction based at least upon a card associated withthe first financial account being expired when the first financialtransaction occurred.

In another aspect, a non-transitory, computer-readable medium storesinstructions that, when executed by one or more processors, may causethe one or more processors to (1) receive application data indicative ofapplicant entries in one or more fields of an application associatedwith a potential account; (2) identify a source computing device viawhich the applicant submitted the application data; (3) retrieve, from asearch history database, search history data indicative of one or moresearch terms submitted to an Internet-based search engine via the sourcecomputing device; (4) determine, by analyzing the application data andthe search history data, that the applicant may not be a person whom theapplicant purports to be; and/or (5) cause an indication of potentialapplication fraud to be displayed to one or more people via one or morerespective computing device user interfaces. The computer-readablemedium may store instructions that include additional, fewer oralternative actions, such as any of those discussed elsewhere herein.

For instance, the instructions may cause the one or more processors toidentify the source computing device at least by identifying an InternetProtocol (IP) address of the source computing device. Additionally oralternatively, the search history data may be indicative of search termssubmitted to the Internet-based search engine from the identified IPaddress. Additionally or alternatively, the instructions may cause theone or more processors to determine that the applicant may not be theperson whom the applicant purports to be at least by comparinginformation included in the one or more search terms to informationincluded in the applicant entries in the one or more fields.

X. Additional Considerations

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement operations or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. These and othervariations, modifications, additions, and improvements fall within thescope of the subject matter herein.

1. (canceled)
 2. A computer-implemented method of identifying fraudulentonline applications, the method comprising: providing, by a computersystem, an online application to a user device, wherein the onlineapplication includes a routine configured to retrieve online searchingactivity associated with the user device; receiving, by the computersystem, a submission of the online application including applicant data;receiving, by the computer system, the online searching activityassociated with the user device; determining, by the computer system,whether the online searching activity associated with the user deviceindicates a search for the applicant data; and in response todetermining that the online searching activity indicates a search forthe applicant data, performing, by the computer system, a fraudmitigation action including at least one of: flagging the submission ofthe online application as potentially fraudulent; or generating anelectronic alert indicating that the submission of the onlineapplication is potentially fraudulent.
 3. The computer-implementedmethod of claim 2, wherein the online searching activity is received asone or more data fields within the submission of the online application.4. The computer-implemented method of claim 2, wherein the onlinesearching activity includes social media activity, and wherein theroutine of the online application is configured to retrieve the socialmedia activity associated with the user device.
 5. Thecomputer-implemented method of claim 2, wherein the online searchingactivity includes an Internet search history, and wherein the routine ofthe online application is configured to retrieve the Internet searchhistory from a search engine on the user device.
 6. Thecomputer-implemented method of claim 2, wherein the submission of theonline application includes a field indicating a GPS location of theuser device, and wherein performing the fraud mitigation action isfurther based on the GPS location of the user device.
 7. Thecomputer-implemented method of claim 2, wherein the submission of theonline application includes an IP address of the user device, andwherein receiving the online searching activity comprises using the IPaddress to query the user device for the online searching activity. 8.The computer-implemented method of claim 2, further comprising:providing the online searching activity as input to a trainedmachine-learning program, wherein performing the fraud mitigation actionis based at least in part on an output of the trained machine-learningprogram.
 9. The computer-implemented method of claim 2, furthercomprising: determining an existing user corresponding to the applicantdata; receiving, from a data source, a current user location of theexisting user; determining whether the current user location correspondsto a location of the user device; and performing the fraud mitigationaction, based at least in part on determining that the current userlocation does not correspond to the location of the user device.
 10. Thecomputer-implemented method of claim 2, wherein determining the onlinesearching activity includes receiving, via a transceiver of the computersystem, the online searching activity over a radio link.
 11. A systemcomprising: at least one processor; a non-transitory computer-readablemedia storing computer-executable instructions that, when executed,cause the at least one processor to perform operations comprising:providing an online application to a user device, wherein the onlineapplication includes a routine configured to retrieve online searchingactivity associated with the user device; receiving a submission of theonline application including applicant data; receiving the onlinesearching activity associated with the user device; determining whetherthe online searching activity associated with the user device indicatesa search for the applicant data; and in response to determining that theonline searching activity indicates a search for the applicant data,performing a fraud mitigation action including at least one of: flaggingthe submission of the online application as potentially fraudulent; orgenerating an electronic alert indicating that the submission of theonline application is potentially fraudulent.
 12. The system of claim11, wherein the online searching activity is received as one or moredata fields within the submission of the online application.
 13. Thesystem of claim 11, wherein the online searching activity includessocial media activity, and wherein the routine of the online applicationis configured to retrieve the social media activity associated with theuser device.
 14. The system of claim 11, wherein the online searchingactivity includes an Internet search history, and wherein the routine ofthe online application is configured to retrieve the Internet searchhistory from a search engine on the user device.
 15. The system of claim11, wherein the submission of the online application includes a fieldindicating a GPS location of the user device, and wherein performing thefraud mitigation action is further based on the GPS location of the userdevice.
 16. The system of claim 11, wherein the submission of the onlineapplication includes an IP address of the user device, and whereinreceiving the online searching activity comprises using the IP addressto query the user device for the online searching activity.
 17. Thesystem of claim 11, the operations further comprising: providing theonline searching activity as input to a trained machine-learningprogram, wherein performing the fraud mitigation action is based atleast in part on an output of the trained machine-learning program. 18.A non-transitory machine-readable storage medium storing instructionsthat, when executed, cause a processor to perform operations comprising:providing an online application to a user device, wherein the onlineapplication includes a routine configured to retrieve online searchingactivity associated with the user device; receiving a submission of theonline application including applicant data; receiving the onlinesearching activity associated with the user device; determining whetherthe online searching activity associated with the user device indicatesa search for the applicant data; and in response to determining that theonline searching activity indicates a search for the applicant data,performing a fraud mitigation action including at least one of: flaggingthe submission of the online application as potentially fraudulent; orgenerating an electronic alert indicating that the submission of theonline application is potentially fraudulent.
 19. The non-transitorymachine-readable storage medium of claim 18, wherein the onlinesearching activity is received as one or more data fields within thesubmission of the online application.
 20. The non-transitorymachine-readable storage medium of claim 18, wherein the onlinesearching activity includes social media activity, and wherein theroutine of the online application is configured to retrieve the socialmedia activity associated with the user device.
 21. The non-transitorymachine-readable storage medium of claim 18, wherein the onlinesearching activity includes an Internet search history, and wherein theroutine of the online application is configured to retrieve the Internetsearch history from a search engine on the user device.